Implement RBAC layer for `runtimeconfig` package

[Emyrk]

Related to coder/coder#14586

If a cache layer is introduced, then dbauthz would be skipped for cache hits. Since the dbauthz is a general settings update, the dbauthz layer cannot sufficiently distinguish the rbac properties of a setting by it's key string alone.

RBAC needs to be woven into runtimeconfig.

One idea is to add some rbac element to Initialize and New so that each field knows it's own RBAC properties.

[spikecurtis]

What do you think about inserting the cache between dbauthz and the real database? We pass db.Store around a lot, and I don't want people to call the low-level config queries and bypass the authorization.

[Emyrk]

@spikecurtis I looked into that awhile back when doing the dbauthz layer. The downside is the interface for db store is massive. So in this case, I'd have to stub out 349 of the 352 functions, since the cache only cares about the functions related to runtime config settings.

The other issue is the runtime config is using a single query to interact with all config settings. Just GetRuntimeConfig(ctx context.Context, key string) (string, error). The dbauthz (at least today), does not know what the setting is, aside from the key.

This is instead of making a different set of CRUD queries for each settings. So the RBAC needs to be defined by the caller somehow. Or dbauthz needs to inspect the key and determine the rbac requirements.