Enable use of async for the KMIP signer?

[ximon18]

In the walking skeleton while the functional test is running and Krill is configured to use only KMIP with a local PyKMIP server, the Krill UI and API are unresponsive (though the metrics endpoint responds just fine).

As the KMIP signer makes sends requests to the erver via TCP+TLS it may benefit from using async Rust code instead of sync Rust code, so Krill via its Tokio framework can be busy doing something else instead of one or more of its threads being stuck waiting for the request to be sent to and the response to be received from the HSM.

However, there are a couple of problems with this:

1. This won't help PKCS#11 signers for which the backend is actually not local but remote but this is abstracted away by the PKCS#11 library that is loaded. The Rust PKCS#11 craqte (https://crates.io/crates/pkcs11/) that I used for the Krill HSM prototype work does not support async and i wonder whether the PKCS#11 interface even makes it possible to support async as a function like C_GenerateKeyPair has no async counterpart that I can see and so the client code is forced to wait for completion of the call. One could place the functiona calls via the PKCS#11 interface in a separate thread to prevent blocking the main Tokio async handling threads perhaps.

2. The Signer trait is sync only and Krill both uses it and depends on it because it calls rpki-rs crate functions which take Signer arguments as input.

[ximon18]

See: https://github.com/NLnetLabs/rpki-rs/issues/161

[timbru]

We should also review the code and see if there are things that could be batched for background processing instead, so that users don't need to wait - especially wrt PKCS#11 which may mean that certain thing just cannot be done as async.