Recent testing has shown that sometimes, errors are mishandled
when using the cryptobox API. The problem is:

(1) Mac check failure is returned using a `bool`, but this doesn't
    have the `#[must_use]` annotation that `core::Result` does.
(2) Cryptobox itself was still using the `Error::MacFailed` which
    was supposed to go away.
(3) Cryptobox itself was not using xoloki's CtAead trait, it was
    still using the variable time thing, and only the return codes
    were changing.

The solution proposed is:
(1) Introduce CtDecryptResult type which is a new-type wrapper around
    `subtle::Choice` which has the must-use annotation. Put this
    in `mc-crypto-ct-aead` crate and use it.
    Previously I was worried to use `subtle::Choice` as an API type,
    but now we have doen that elsewhere and it hasn't caused churn
    or problems.
(2) Make cryptobox return CtDecryptResult instead of bool as it had
    been doing, and nuke the `MacFailed` error variant which should
    be gone now. Make cryptobox also use the same version of `aead`
    crate that `mc-crypto-ct-aead` crate is exporting.
(3) Make cryptobox actually use the constant-time aes-gcm.

Besides these issues, while updating the fog hint code that uses this,
we noticed:
(4) The fog hint decryption code which used cryptobox is needlessly
    complicated, uses an RNG for no real reason, and introduces
    unnecessary types with special implementations of subtle trait.

Proposed change:
(4)  We have now made it completely determinsitic, which is better
    for testability, and documented that it doesn't make changes
    if decryption fails, which is all that is needed. Then the
    caller can decide what value the output parameter should have
    in that case. We deleted the unnecessary types and functions.

…ternal)

Co-authored-by: James Cape <jamescape777@gmail.com>

Co-authored-by: James Cape <jamescape777@gmail.com>