feat: optional signing providers

[pawelstepien-da]

.

[pawelstepien-da]

@mjuchli-da Do you think we can remove arguments 'db' and 'signing-db'? If not, then I will just remove TODO comment.

[mjuchli-da]

i don't think we can

[mjuchli-da]

Thanks! It looks good but let us investigate if we can simplify the configuration as outlined in the comment below.

[mjuchli-da]

i don't think we can

[mjuchli-da]

I actually think we might not need this: what if we just assume that if the config holds a record for a signing provider, then the intention is to enable it. That means, by default, everything is disabled, but if the property fireblocks with all its fields exists, then we plan to enable the driver.
This should also work fine for walletKernel and participant which do not hold sub-fields – here we can use the ~ tilde symbol as per yaml standard.

The reason why I think we should at least check if this is doable is because it might make the subsequent plug&play of signing drivers more user friendly.

[pawelstepien-da]

We could just assume that lack of provider's object in config means it won't register, but it is a breaking change that would require changing config after updating to Gateway version that will have this feature.

Explicit opt-out is one of two ways of preventing breaking changes I implemented, and the second is in case of missing config properties, like signingProviders.blockdaemon.baseUrl, to fallback on environment variables that were used before.

I see 3 options depending on how we want to balance no breaking changes vs simpler config and easier plug&play:

1. Keep as is. No breaking changes, more complexity.
2. Remove enable field, but keep checking environment variables as fallback for values that are now supposed to be in WG config. i.e if you have all env vars needed to register blockdaemon but no signingProviders.blockdaemon in config, it still registers. Only wallet-kernel and participant have breaking changes, simpler config for users, but still a bit convoluted for us to keep supporting deprecated env vars.
3. Only existence of signingProviders.x entry allows registration of signing driver. Simplest config and code maintenance, but absolutely requires updating config after upgrading to WG version with that feature, or no signing provider will register.

[mjuchli-da]

I suggest going with option 3. With the browser extension deployment, we will anyways need to opt-in a different default setup (e.g. no postgres but extension storage instead).

[mjuchli-da]

We agreed that if signingProviders is missing, we will supply a default config:

"signingProviders": {
        "participant": {},
        "gateway": {},
        "fireblocks": {},
        "blockdaemon": {},
        "all the rest": {},        
    }