Complete tracking and expiry of valid JWKs via the AuthenticatorState object (#13576)

I apologize for the large PR (although a lot of the + lines are docs and
tests) - this turned out to be much more complicated than I could ever
have guessed.

The main challenge here was managing the creation of the new system
object at `0x7` that is used to track the authenticator state. It can't
be created until one epoch after the protocol upgrade that brings in the
new framework, and we have to be careful not to create it twice. I tried
many different approaches before arriving at this one.

The system works as follows:
- `ChangeEpoch` is replaced with `EndOfEpochTransaction`, which contains
a list of transactions to perform at the end of the epoch. For now the
possible end-of-epoch actions are ChangeEpoch, AuthenticatorStateCreate,
and AuthenticatorStateExpire.
- If the protocol feature flag is off, do nothing.
- If the feature flag is on, check if the authenticator state object
already exists (and cache its existence for the duration of the epoch).
- If it does not exist, then at the end of the epoch, add an
`AuthenticatorStateCreate` tx just before the `ChangeEpoch` (inside
EndOfEpochTransaction).
- This was necessary because doing the creation from within
`ChangeEpoch` posed the following difficulties:
- ~~The start version of the authenticator state object would be
variable instead of being fixed at 1.~~ Using EndOfEpochTransactions
re-introduces this issue, which required adding the correct
intial_shared_version to the transaction data.
- I could not find an easy way to ensure that the creation could only
happen once in this scenario.
- This had the added benefit of giving a simple way to probe for
existence of the `create` function. If the `AuthenticatorStateCreate` tx
fails due to `FunctionNotFound` when attempting to augment the
checkpoint, we simply omit the tx.
- If it does exist, then we add an `AuthenticatorStateExpire` tx just
before the `ChangeEpoch` tx.
- I had similarly hoped to do the expiry from within the `ChangeEpoch`
tx, but that would have required the set of shared_input_objects to the
`ChangeEpoch` tx to change at a certain point. And because that point is
delayed until the epoch after the protocol version bump (due to
framework upgrade) it would have been extremely ugly to do this.
- There would be no easy way to pass in a `min_epoch` argument to
ChangeEpoch tx without add a ChangeEpochV2 transaction type with an
additional argument. (as well as a new entry point to the
`advance_epoch` function).
- CheckpointExecutor has been modified to treat both of these "end of
epoch" txns the way we previously treat `ChangeEpoch` - i.e. only
execute it via CheckpointExecutor after all other transactions have been
executed.
- I tried to avoid this by having `handle_consensus_output` insert the
`AuthenticatorStateExpire` tx, but this proved to be very awkward. It's
not possible to tell whether the tx should be added until the
`EndOfEpoch` messages have been processed, and by that point it is too
late to add new system transactions.

The state machine for voting on JWKs, approving them, and created
`AuthenticatorStateUpdate` transactions remains basically the same as in
the previous version of this PR.

TODO: I am still working on a few tests, in particular one that provides
multiple different JWKs from multiple providers to the TestCluster.

---------

Co-authored-by: Mark Logan <[email protected]>

Author: mystenmark