This will be necessary to avoid reentrancy hazards, in case the application
code makes other wormhole API calls from the callbacks for
get_unverified_key(), get_verifier(), or get_message().
Previously, w.when_verified() was documented to fire only after a valid
encrypted message was received, but in fact it fired as soon as the shared
key was derived (before any encrypted messages are seen, so no actual
"verification" could occur yet).
This fixes that, and also adds a new w.when_key() API call which fires at the
earlier point. Having something which fires early is useful for the CLI
commands that want to print a pacifier message when the peer is responding
slowly. In particular it helps detect the case where 'wormhole send' has quit
early (after depositing the PAKE message on the server, but before the
receiver has started). In this case, the receiver will compute the shared
key, but then wait forever hoping for a VERSION that will never come. By
starting a timer when w.when_key() fires, and cancelling it when
w.when_verified() fires, we have a good place to tell the user that something
is taking longer than it should have.
This shifts responsibility for notifying Boss.got_verifier, out of Key and
into Receive, since Receive is what notices the first valid encrypted
message. It also shifts the Boss's ordering expectations: it now receives
B.happy() before B.got_verifier(), and consequently got_verifier ought to
arrive in the S2_happy state rather than S1_lonely.
Since input_code() sets the nameplate before setting the rest of the code,
and since the sender's PAKE will arrive as soon as the nameplate is set, we
could got_pake before got_code, and Key wasn't prepared to handle that.
* finally wire up "application versions"
* remove when_verifier (which used to fire after key establishment, but
before the VERSION message was received or verified)
* fire when_verified and when_version at the same time (after VERSION is
verified), but with different args
