Add a database-backed secret resolver (basically identical to the config one, so consider refactoring that)

[alecthomas]

Currently we have an ASM resolver + provider in production, which results in all operations hitting ASM, and FTL in production being restricted to a single secret source. By having a database resolver, we can reduce the calls to ASM, and support multiple providers (eg. a local Linux keychain for single-host deploys, inline (needs additional encryption), etc.)

[safeer]

I've got most of this implemented, but seems like we need to think through the Router (fka Resolver) vs Provider relationship. There can only be one router, but there can be multiple providers. When projectconfig_resolver was the only router, this made sense since you'd read and write to the provider, and update the router (i.e. adding references).

Since then, the Router vs Provider relationship has become conflated, with functionality split between the two. See asm.go which conforms to both, and db_config_provider and db_config_resolver, the latter only implementing List.

With two separate secret providers for production (either ASM or DB) the assumption of keeping a router up to date with all changes to providers doesn't hold anymore.

It seems like things will be a lot cleaner if we either support multiple Routers, or remove the Router notion entirely and keep Resolvers with projectconfig as the only special case.

cc @alecthomas @wesbillman

[alecthomas]

There should only ever by a single router. In the ASM case this relationship still held true - there was a single router and a single provider. The router should be removed from ASM now that we have a DB router.