Add session command data and enforce-session builtin

[imalsogreg]

Asana task

Goals:

• Add a builtin to allow (enforce-session keyset-foo), which enforces that "keyset-foo" is available in the environment as a "session signer".
• Add the notion of session signer to Command. A session signer is the public key of a user who has somehow been authenticated, for example by an authentication token that relates a user to a public key in some external system.
• Pass the session signer from Command through to EvalEnv, so it's available to the implementation of enforce-session.

Wish list for review:

• Basics: readability, clarity
• Reevaluate assumptions about adding sessionSig to Payload. (I'm not 100% sure this is still needed). For example, we may be able to remove it from Payload and MsgData, and make it the responsibility of whoever invokes the Pact interpreter, to override _eeSessionSig in the environment. I'm not sure if this has other drawbacks (for example, is it insecure to fail to record a SessionSig that authenticated a transaction?)
• As Stuart pointed out, SessionSigner doesn't belong in the payload, so I've moved it out. Whoever sets up the EvalEnv now sets SessionSigner directly.
• Is it ok that I had to change the golden tests for encoded continuations? That's probably not ok, so SessionSigner is no longer part of the Payload, the hashes no longer change. 👍

[sirlensalot]

I feel like something is getting lost in translation. My previous comment:

Sessions are a container-provided trusted value, whereas Commands are signed by user.
Thus, the container should be directly instrumenting any Session credentials directly into the environment.

"directly instrument" simply means "call setupEvalEnv in the container". There are many reasons why sessions have nothing whatsoever to do with transactions or commands:

1. The user has no way to specify; sessions are entirely controlled by the container.
2. The session obviously spans multiple commands and indeed is unaffected by the execution of any given command.
3. Command is the single most important type in our API as it's literally how every single blockchain transaction is executed so it's trust paradigm cannot be modified. The triple of (hash,sigs,payload) is an invariant: the hash directly reflects the payload and the only extraneous information are sigs that sign nothing more than the hash.

[imalsogreg]

Makes sense, thanks for the explanation! The PR is updated now so that Command and Payload do not include a session public-key. So session-pubkey isn't exposed via any API of pact nor any of the downstream projects that use pact, but a hypothetical new container service would be able to set it while provisioning its EvalEnv. For example a hypothetical new pact server than manages user authentication and sessions could set up session pubkey. (As we discussed on slack. restating it here for the github record).

[jwiegley]

Suggested change

	updateEnvMsgSession
	updateEnvMsgSession

[jwiegley]

Is this code just checking whether matchKey equals publicKeyText?

[imalsogreg]

Just a tad more - matchKey isn't a single key, but a predicate that checks if publicKeyText is an element of the keyset keys.

The code here is confusing. I've tweaked this part to make it more clear.

[emilypi]

Looking good so far!

[emilypi]

what's the syntax for a cap here? Can we get a more complex example?

[emilypi]

Do we want to error this hard instead of calling evalError' or dying some other way? I seem to remember some discussion of this but I'd like to see it fleshed out here in the PR.