Prepare changes for config version 2

[carabasdaniel]

No description provided.

[github-actions]

Pull Request Test Coverage Report for Build 6629312535

• 185 of 294 (62.93%) changed or added relevant lines in 11 files are covered.
• 10 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.4%) to 41.839%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/app/edgedir.go	2	3	66.67%
pkg/cc/config/config.go	3	4	75.0%
pkg/testing/client.go	2	3	66.67%
plugins/edge/sync.go	0	2	0.0%
pkg/app/console.go	0	3	0.0%
pkg/app/ui/handler.go	0	10	0.0%
pkg/app/authorizer.go	37	52	71.15%
pkg/app/topaz.go	127	203	62.56%

Files with Coverage Reduction	New Missed Lines	%
pkg/cc/config/config.go	1	75.0%
pkg/app/ui/handler.go	2	0.0%
pkg/app/topaz.go	3	61.06%
pkg/app/authorizer.go	4	68.75%

Totals
Change from base Build 6615738224:	0.4%
Covered Lines:	1415
Relevant Lines:	3382

---

💛 - Coveralls

[gertd]

@carabasdaniel

I took this PR together with the service-host PR (aserto-dev/service-host#6) for a spin.

A couple of observations:

• It seems we check the config version too late, when starting topaz pointing to an old config

It first fails with:

2023/10/24 13:02:49 failed to create new config: failed to unmarshal config file: 1 error(s) decoding:

* 'api' has invalid keys: authorizer, exporter, importer, model, reader, writer

I fixed up the config, fixing the top

api:
  health:
    listen_address: "0.0.0.0:9494"
  services:

intentionally making the mistake to not remove the:

      health:
        listen_address: "0.0.0.0:9494"

section, which now fails with

2023/10/24 13:05:04 failed to create new config: failed to unmarshal config file: 6 error(s) decoding:

* 'api.services[authorizer]' has invalid keys: health
* 'api.services[exporter]' has invalid keys: health
* 'api.services[importer]' has invalid keys: health
* 'api.services[model]' has invalid keys: health
* 'api.services[reader]' has invalid keys: health
* 'api.services[writer]' has invalid keys: health

Now removed the health keys, to then fail with:

2023/10/24 13:08:08 failed to create new config: failed to validate config file: unsupported config version

The expectation is that we first check the version before attempting to unmarshal the config payload.

---

The cleanup, implementation yields the same results as the currently in-place workaround in terms of correctly closing the database in the correct order, so that is good!

I wonder if it would make sense that the context that is used to capture the os.Signal() should be passed down to the service implementations, so that we can respond correctly and drain connections. Right now we instantly close everything down, where I would hope we can get to the behavior that when the cancellation is called on the context we:

1. stop accepting new requests
2. drain the existing request using an acceptable timeout
3. shutdown the stateful resources
4. shutdown

I cannot envision if I can achieve this with the current cleanup function approach.