Enabling the Directed Messaging protocol in the %ames vane is done by changing the default core that handles incoming and outgoing packets (from |ames to |mesa).

TODO(s)

• Less loud verbosity—we are going to ahoy ships that might be offline/behind so all this slogs should be under the sun.veb flag
• update app/hood (via lib/helm; maybe as a separate library/state?) with handling peek retries, and timeout expiration for all or specific peers.
  • support passive mode: on contact, attempt migration
  • support massive mode: on user action, attempt migration of all online %408 peers.
• timer on failed ahoys? we will still %prob on hearing packets from that ship
• %aqua tests
• more unit tests
• ...

Instead of trying to migrate everybody, to reduce the number of packets in-flight, we only send the %ahoy $plea when we receive a legitimate %ames packet from a peer, and our default network core is %mesa. This is call passive mode.

We handle the following scenarios considering where state is stored (in peers.ames-state if previously communicated using |mesa or chums.ames-state if using |mesa), and what type of packet arrives (%hear for %ames packets, %heer for %mesa packets).

If the user wants to we also support mass migration of all peers that are online and support arvo %408

On both %hear and %heer with first try to find the peer in state, if not, this is a first contact and we use what default protocol core we have in state to discern what to do with the peer.

For %hear packets:

::  [%mesa ~]
::
::    a peer sends us an %ames packet, but %mesa is our default core
::    and have not communicated previously
::
::  [%mesa ~ %alien *]
::
::    %mesa is our default network core. we might have outstanding
::    poke/peeks we have sent, but the keys are missing and the peer 
::    sends an %ames packet — if nothing outstanding, the peer has 
::    first sent an %ames packet, we dropped it and asked for the key, 
::    then the peer sent a %mesa packet
::
::    XX log as misbehaving peer?
::
::  [%mesa ~ %known *]
::
::    if we can find the peer in chums, it means that they sent an %ahoy
::    $plea, we migrated them, but they haven't heard our %ack, and have
::    not migrated us, so they could still be resending the $plea.
::    in this case we just ack the plea
::
::    if this was not an %ahoy plea, check if we can move the ship back
::    to .peers, if this is a first contact (e.g after a breach)
::
::    (any %fine requests should have been migrated and responses should
::    only come via %heer or %mess)
::

For %heer packets:

::  [%mesa ~]
::    only if %mesa core enabled (not before this PR)
::
::  [%ames ~]
::    a peer sends us a mesa packet, but %ames is our default core
::
::  [%mesa ~ %alien *]
::    %mesa is our default network core. we could have outstanding
::    poke/peeks, but the keys are missing and the peer sends up a
::    %mesa packet
::
::  [%ames ~ %alien *]
::    %ames is our default network core. we could have outstanding
::    poke/peeks, but the keys are missing and the peer sends up a
::    %mesa packet — if nothing outstanding, the peer has first
::    sent an %ames packet, we dropped it and asked for the key,
::    then the peer sent a %mesa packet
::
::    XX log as misbehaving peer?
::

• (easy case) received ames/mesa packets with no state, handle with the corresponding core and, if %mesa packet, enqueue %ahoy $plea

• received ames/mesa packets with the ship as %alien, but handled by other network protocol than the one the packet belongs to

  • this could be peer doing something weird, (maybe a double boot) if they first initiated communication, but it could also mean that we have different default network core handling in state, and we have tried to communicate, but one of the ships is still waiting to hear the keys (the other one will have already move from %alien to %known).
    • the ship that has the other ship as %alien is not sending packets, but it could receive them, so we take the packet and handle it using the protocol the packet belongs to, and of we had the %alien ship in .chums, we move it back to .peer and enqueue an %ahoy $plea, if the other way around, we move the %alien ship to %mesa, and wait for the keys to arrive.

• the ship is %known, but the packet belongs to the other protocol:

  • if the peer-state/fren-state not belonging to azimuth data is bunted, that means a breach, and the breached ships booting using a pill that has as default the other network protocol.
    • in this case we move the ship to the protocol belonging to the packet, and if that was an %ames packet, we enqueue an %ahoy $plea—this only happens if we have the ship in .chums
  • if there is flow state:
    • if the ship is in .chums and we get an %ames packet we don't know if the other side supports %mesa so we enqueue a special %yoha $plea that is just going to be acked, but will trigger the receiver to migrate us to %mesa inmediately.
    • if the ship is in .peers and we get a %mesa packet we migrate the peer immediately dropping the packet which will be resend—this packet could be a %yoha $plea or another $plea

• Instead of enqueuing the %ahoy $plea while processing the %hear event, we defer that to an agent (currently %hood) that will first peek if the ship is running arvo %408, and it so send the $plea.