Proposal: Do not use persistant storage in entropy-tss

[ameba23]

Currently we use persistent storage (the on-disk key value database) to store the following things in entropy-tss:

• The network keyshare, if we have one.
• Our secret keys for TSS account / x25519 encryption.
• Block numbers and other data for various security checks

There are two problems with this:

1. Although our kvdb offers encryption with a password, we currently don't have a way of encrypting it such that the operator of the host machine cannot access it.
2. Even if we solved (1), since the secret keys used in authentication persist re-starting the VM running the entropy-tss process, it is possible that the operator restarts with a modified version of the binary but keeps the (encrypted) authentication keys intact. We have no way of detecting this in order to request a new attestation.

For these reasons i think we should consider removing the on-disk kvdb, and have secret data be lost if the VM process is killed.
That is, every time the entropy-tss binary is launched, fresh TSS account / x25519 keys are generated. These should be submitted to the chain together with a request for attestation. The chain should then assume that any old TSS account associated with this PCK is 'dead', and therefore remove them from the signer set at the next reshare (as part of slashing mechanism).

My proposal of how to do this, would be that the AppState struct would look like this:

#[derive(Clone)]
pub struct AppState {
    listener_state: ListenerState,
    pub configuration: Configuration,
    tss_signer: PairSigner<EntropyConfig, sr25519::Pair>,
    x25519_secret_key: x25519_dalek::StaticSecret,
    keyshare: Arc<RwLock<Option<KeyShareWithAuxInfo>>>
    new_user_last_block_number: Arc<RwLock<Option<u32>>>,
    ...other block numbers etc used in various checks (could also be in a separate struct)
}

The secret keys never change so don't need to be behind a mutex.

For the keyshare, using RwLock rather than Mutex means we can have multiple readers concurrently - so wont effect being able to run several signing protocol instances at once.

[ameba23]

Related to: #1015

[JesseAbram]

as for all this makes sense, for the proposal tho,

We can just create one hashmap instead of an individual slot for each item, would keep the same structure as our kvdb