Replace ad-hoc envar "protocol" with something more structured

[alecthomas]

Currently we utilise a random set of environment variables such as FTL_CONFIG, FTL_ENDPOINT, LOG_LEVEL, etc. to propagate configuration state between the runner and the module it is executing. We should come up with something less gross.

One option would be to double down on using envars for this, but have a data structure that encapsulates it all. Another option would be to push some of this back to the Runner over gRPC. That is to read a config key or secret key, the user code calls a gRPC method on the Runner.

[alecthomas]

Just adding triage back to this one because someone needs to take this, so we should discuss next week.

[alecthomas]

Stupid bot.

[matt2e]

• design doc
• have a single get into ftl from user code that returns structured data for all of this

[matt2e]

Doc: https://hackmd.io/@ftl/SyynEK2eC

[wesbillman]

@matt2e is this issue related to this work here? Or something else #919

[alecthomas]

That one is more related to pulling config/secrets from different sources in production - ie. a DB table for config, and AWS Secrets Manager for secrets. The plumbing is there in the config resolvers, we just need implementations for them.