Seed recovery process to survive kettle restarts

[MoeMahhouk]

In this PR we tackle the issue of losing the seed that generates the private key upon a kettle restart.
Here we rely on the bootstraping and onboarding steps to keep the exchanged ciphertext of the seed onchain.
This way, upon deriving the private key, if kettle has restarted, it will be detected that the seed is not there and initiates the recovery process.
A follow up task would be to discover ways to tackle sealing key revocation and renewals.

Note: this PR relies on the refactoring of volatileGet precompile in this PR

This PR adds the following:
1- seed recovery proccess
2- fix a minor bug in the offchain registry function (the address checking was wrongly placed)
3- Add unit tests to check the validity of the seed recovery process
4- Modify the kettle-bootstrap.ts script to do the registration and onboarding to enable seed recovery functionality
5- Refactors the Andromeda interface to use the volatileGet updated version from this PR

[MoeMahhouk]

There is still a bug upon restarting the kettle during the Timelock demo.
For some reason the KeyManager won't function anymore and it requires to redeploy the key manager smart contract again for it to work.
Further debugging is currently in process. (This PR won't be merged until this is fixed)

[amiller]

at first review, this seems redundant because the onboarding process already uses sealing to store the seed. So there isn't need for more flow, we just need to finish automation for the onboarding flow.

[MoeMahhouk]

at first review, this seems redundant because the onboarding process already uses sealing to store the seed. So there isn't need for more flow, we just need to finish automation for the onboarding flow.

I don't get what you mean this seems redundant?
This is for the scenario that a kettle restarts and loses its volatile seed that is used for the key derivation.
This way, it will be able to recover it automatically without the need for new onboarding.
It will also not fail for any incoming requests or during execution (timelock demo)

[amiller]

I'm still opposed to this merge fwiw for the reason of redundancy stated above