UX interaction via blocking modals are put into its own thread
so that the background UX can update while menus and modals are
popped up.
Still some bugs to work out to make this fully implemented,
but this is the major work fleshed out.
The prediction API now takes an API token. This is a 128-bit
number that gets passed to the prediction engine, and it's meant
to be unique for every context that requires a predictor.
It's up to the prediction engine to do anything with the token.
For the "null" engines (such as the icontray for `vault` and
`tts`) the token is just ignored. But for example, in `shellchat`,
the API token is used to store a history record in a HashMap on
a per-token basis. This means that every app that uses the
`shellchat` history function gets their own history that can only
be read out by that app.
The actual token itself is mostly passed through the API. The
token storage is in the Context layer (each Context has a record
for a token, that starts as `None`), and is passed down to
the predictor every time the context swaps, and the predictor
receives the token and passes it back if the token was `Some`,
or allocates a new random token if it was `None`.
Note that everything is a Context, including, for example, menus and
modal dialog boxes, but not all contexts have predictors. Only
Contexts that ask for a predictor have them. This mechanism
works smoothly in this model (as opposed to other hacks and work-arounds
previously tried getting to this solution).
i've extracted the key parameters from the test suite and confirmed that
that the hash value is computed correctly on their side.
i've also confirmed that the hash value is computed correctly from
the locally computed key.
so what's gone wrong is the devired secret key doesn't match what's
on the other side.
possible issues could be either a PK serialization issue, or something
wrong in the DH exchange itself.
trying to debug why PIN authentication doesn't work. looks like
Cosekey conversion is fine, the data is arriving OK...but the
dh key exchange is not generated the expected shared secret.
Had two JSON entries with the same key, which meant you had
a 50/50 chance of a rebuild being triggered depending on which
entry was picked for the build. :-/
