Signing e2e tests

[musitdev]

Summary

• RFCs: Link to RFC, Link to RFC, or $\emptyset$.
• Categories: any of protocol-units, networks, scripts, util, cicd, or misc.

e2e tests must follow the normal deployment and execution process of Movement products that use signing.
This process is:

• execute a setup that defines the configuration.
• start all needed processes.
• start the application or execute the test that signs.

The Key Manager will be used to allow to define a key/provider during the setup and to provide the key when the application is executed.

The e2e tests are divided the same way: a setup binary that defines the key used by the test, and the test (see movement-signer-e2e-test crate).

This PR adds the following crates to integrate this process:

• config: define the key manager configuration. It allows defining keys that will be loaded by the key manager.
• setup: create the Key Manager configuration with the provided key.
• e2e-test: contains all the e2e tests with the setup associated to each test.

Another point is that to test AWS KMS or HashiCorp Vault the authentication data must be provided to run the test. It can be acceptable on the developer PC but not in the CI because they will be visible to everyone. As a workaround, a local signer provider will be developed to allow to sign with a newly generated key during the test. This local provided will be used for CI test.

Changelog

Testing

One test is defined to illustrate the process. It signs a transfer tx but depending on the executed setup it doesn't use the same key/provider.
Two setups are defined: a local to use the local provider and an AWS KMS to use AWS one.

I've started to add some process compose script to run the test. It is still a work in progress.

Outstanding issues

Key Manager API must be updated to follow this model and the Signing that is not object safe can be an issue to get dynamic Signer depending on the executed setup. Some work must be done here to see if it can be use dynamically using a box or an enum for example.

[l-monninger]

Enum variants should not be all caps: https://rust-lang.github.io/api-guidelines/naming.html#casing-conforms-to-rfc-430-c-case

[musitdev]

Yes, I thought it was UpperCamelCase when the variant contains fields and all upper case when it's a constant. I'll update.

[l-monninger]

This doesn't really show me a lot to do with how you integrate this with the mcr_settlement_client crate which is where the e2e testing would take place. That's what I would like to see earlier than later in this next sprint.

[musitdev]

mcr_settlement_client/test_client_settlement test is more an integration test because it doesn't need all the node setup process. It only uses an anvil process. It can be updated the same way it's done here: https://github.com/movementlabsxyz/movement/blob/musitdev/alloy-integration/util/signing/integrations/eth/tests/aws_test.rs
In this PR, I propose a way to manage how the setup/config process can be handled to integrate the signing API in the node execution process (setup->config->execution). To do that, we need a way to define the key during the setup and a way to get the key when the node is executed. For example, the setup key definition need to handle when the execution connects to AWS KMS with auth token (local on a PC for example) or a local signer provider when use in the github CI. The why I define 2 setup and one test.
If we agree on this conception, the integration in the Suzuka node / bridge will be only to update the corresponding setup to define the key the same way as the setup example and update how the Alloy provider is loaded, as done in the test.