refactor(daemon): Move mail delivery to agent public facets

[kriskowal]

Toward delivering mail over the network, this change introduces a deliver method on guest and host agents that accepts arbitrary messages into the agent’s inbox. Any other agent can send mail to any other local agent for whom they have a handle and cannot spoof their sender handle.

This is a net simplification, since it reduces our dependence on the internal facet of agents and requires less machinery because it treats messages as capabilities on the wire, freely exposing and carrying identifiers. We no longer have separate internal and external representations of messages and pet name “dubbing” is deferred to the UI. This in turn enables us to defer to the UI the question of whether to query the name for each identifier once or watch for changes.

Stacked on #2184

[kriskowal]

Just added a change to get Familiar Chat back into working order, since this changes the public type of messages. Now, both the CLI and WUI use reverseIdentify to translate the identifier-on-the-wire to their agent’s pet names. The WUI will need a follow-up to utilize followLocatorNames.

[kriskowal]

Big fan of this PR 👍

Some optional suggestions in my first pass. Conflicts need to be resolved, then I'll come back for a second and likely final look.

Good for another pass. I’ve responded to your feedback (and my breadcrumbs) and also appended one commit that has turned out to be necessary: refactor(daemon): Handles are mail delivery facets. This is a pretty big deal. Handles become public capabilities to both deliver mail and also to verify the authenticity of received mail. I used a sealer/unsealer pattern.

In testing this, I discovered that mail delivery over the network will require us to ensure that we only have one live CapTP session between any pair of nodes so we can do grant-matching (so that an envelope that takes a round trip through CapTP comes back as the identical reference to the one sent). To do that, we need to negotiate crossed hellos (so one node knows to drop either its outgoing or incoming connection if nodes attempt to connect to each other concurrently). And once we do that, we need to have application level key pair cryptography to ensure an attacker can’t induce a node to drop a legitimate connection or impersonate another node’s handles.

That is to say, I had hoped that this would be as much scope as we needed to take for a demo. We will have to do at least grant-matching for a demo. We’ll have to do cryptography to be standing on a firm security model, even if we have redundant cryptography relying on Tor or TLS for confidentiality.