* InputHelper returns full words, not just suffixes. I liked the fact that
suffixes made it impossible to violate the "all matches will start with
your prefix" invariant, but in practice it was fiddly to work with.
* add ih.when_wordlist_is_available(), so the frontend can block (after
claiming the nameplate) until it can return a complete wordlist to
readline. This helps the user experience, because readline wasn't really
built to work with completions that change over time
* make the Wordlist responsible for appending hyphens to all non-final word
completions. InputHelper remains responsible for hyphens on nameplates.
This makes the frontend simpler, but I may change it again in the future if
it helps non-readline GUI frontends.
* CodeInputter: after claiming, wait for the wordlist rather than returning
an empty list
* PGPWordList: change to match
This has the unfortunate side-effect that e.g. typing "3-yucatan-tu TAB"
shows you completions that include the entire phrase: "3-yucatan-tumor
3-yucatan-tunnel", rather than only mentioning the final word. I'd like to
fix this eventually.
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
d=M_close() will always do the verbose clean shutdown thing, and the Deferred
won't fire (e.g. we won't move to state "Ss") until we've deallocated our
server resources (nameplates and mailboxes), and we've finished shutting down
our websocket connection. So integration tests should wait on the Deferred to
make sure everything has stopped moving and the reactor is clean.
CLI applications that are following the success path can use M_close() and
wait on the Deferred before terminating.
CLI applications that wind up on some error path can either use M_close(), or
just SIGINT and leave the server to GC stuff later.
GUI applications can use M_close() but ignore the Deferred, and assume that
the program will keep running long enough to get the deallocation messages
through.
GUI+DB applications can use M_close() and then stop recording state changes,
and if the program remains running long enough, everything will be
deallocated, but if it terminates too soon, the server will have to GC.
Starting to draw a distinction between clean-close and abrupt-halt. At least,
if we're in the connected state, wormhole.close() should take its time and
free up server-side resources (nameplate/mailbox) right away, rather than
relying on GC/timeouts to release them.
It might be useful to make separate "clean" wormhole.close() and "abrupt"
wormhole.halt() API calls, except that really when would you ever call halt?
To be realistic, only one of two things will happen:
* connection happens normally, app finishes, calls "clean" close()
* app terminates suddenly, via exception or SIGINT
The problem with defining .close() is that I have to make it work sensibly
from any state, not just the one plausible "connected" state. Providing
.halt() requires defining its behavior from everywhere else.
