Use Trait in favor of enum for SecretManager

[Aconitin]

Description

(Copied over from Discord here )

We're trying to switch from Chrysalis to Shimmer (for our identity management product) and we're having an issue:

We would like to store our keys not in Stronghold but in a PKCS#11 compatible HSM. However, currently, all relevant APIs in iota_client require an instance of the SecretManager (https://github.com/iotaledger/iota-sdk/blob/develop/sdk/src/client/secret/mod.rs#L102) enum. None of the enums variants seem to fit our current usecase.

Motivation

Only allowing Stronghold or Ledger Nano as key storages doesn't really work for industry^^

Requirements

From our perspective, it would make sense to

• Either add a generic variant to SecretManager that contains a T: SecretManage (aka a type that implements SecretManage (https://github.com/iotaledger/iota-sdk/blob/develop/sdk/src/client/secret/mod.rs#L59);
• Or let APIs in iota_client that require SecretManager instead require SecretManage (which is implemented by SecretManager currently anyways (https://github.com/iotaledger/iota-sdk/blob/develop/sdk/src/client/secret/mod.rs#L227))
  ( - Or implement the PKCS#11 interface as an enum variant, but while this is probably the quickest fix, it really is also an ugly workaround and wouldn't really solve our issue since we're forking cryptoki anyways since they're missing EDDSA (Add MechanismType::CKM_EDDSA & Mechanism::Eddsa parallaxsecond/rust-cryptoki#113))

Open questions (optional)

Any help/input would be much appreciated 🙂

Are you planning to do it yourself in a pull request?

Maybe?