feat(core): ability to run a set of isolated services

[strantalis]

This pr resolves #1033

It introduces two new config values mode and sdk_config at the root level. It also removes the enabled field on a service.

Mode now takes a list which could be all, core or a specific namespaced service for example kas. You can also combine modes like core,kas.

When running in something other than core or all you are required to specify a sdk_config object. This is because the core services will be remote now and not over the internal IPC server.

[pflynn-virtru]

suite

[dmihalcik-virtru]

Is the migration stuff part of this PR or could it be moved to its own?

Also, will people need to update their config files after this change (what breakages if any could exist when using an old config file with this one)?

[jrschumacher]

I think we should describe what we expect to happen.... and on this note maybe we need to add config versions so we can detect changes in the future? This won't work for config maps.

1. Without Mode the platform should fail to start and make note of the recent changes
2. If Services still have Enabled we should ignore unless validation exists

There are libs that validate yaml files and refuse to function if they don't meet the schema. For instance, WebPack and Rollup in JS land. Would this be critical to add?

[jrschumacher]

Is the migration stuff part of this PR or could it be moved to its own?

@dmihalcik-virtru this refactor is really focused on the serviceregistry since the modes impacts the way that was implemented.

Sean brought me in during his refactor (pair programming) to check with me on the original implementation. I agree with this refactor since it's more clear. Also with respect to OpenTDF Policy is the only service that uses a DBClient, and we have extensive integration tests that are passing.

If I missed a specific section you're concerned about, would you point that out to me?

[strantalis]

@jrschumacher @dmihalcik-virtru The default mode is all. In opentdf I don't think we ever disable any services that come out of the box. So for now its an upgrade documentation exercise for our internal product. I haven't even begun to think about versioning the config and what complexities that brings versus just have really detailed upgrade notes.

[jrschumacher]

I agree. Default should be monolith, and we can state that this is not a recommendation for a secure production environment. Additionally, I don't think OpenTDF as a group should be offering production advice, since that typically involves liability and insurance.