TKVSM initialization handles when runtimeConfig is provided as a Supplier

[rhuffy]

General

Before this PR:
TransactionKeyValueServiceManager initialization assumes that the Atlas runtime config is provided as a Refreshable.
We also support users providing the config as a Supplier under the runtimeConfigSupplier field.

After this PR:

This PR properly handles TKVSM initialization when the runtime config is passed using runtimeConfigSupplier. It is already asserted elsewhere that runtimeConfig XOR runtimeConfigSupplier is present.
==COMMIT_MSG==
TKVSM initialization handles when runtimeConfig is provided as a Supplier
==COMMIT_MSG==

Please tag any other people who should be aware of this PR:
@jeremyk-91
@jkozlowski

[changelog-app]

Generate changelog in changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

TKVSM initialization handles when runtimeConfig is provided as a Supplier

Check the box to generate changelog(s)

• Generate changelog entry

[jeremyk-91]

Good spot! I think we already do this resolution of the two suppliers earlier in the method though (back on L375), and so we should just use the results.

Basically, we shouldn't be calling runtimeConfig() or runtimeConfigSupplier() directly outside of where we resolve it to a more canonical thing.

(Also, as a drive by: it would be good to, while you're here, also clean up the other misuse of runtimeConfig(), which is in setUpMetricsAndGetMetricsManager().)

[jeremyk-91]

Well spotted - this does look like a mistake we made in #6984 😅

That said, I'm not sure this is the right way to fix it - we already wrap the runtime config in a Refreshable on lines 372-373. Notice that other code around this uses runtime rather than runtimeConfig() or runtimeConfigSupplier(). So I think here this should just be runtime.map(config -> config.tkvs().orElseThrow(...)).

[jkozlowski]

Can we hoist this up somewhere?

[rhuffy]

I've refactored this to use the existing runtimeConfig <-> runtimeConfigSupplier resolution logic

[jeremyk-91]

👍 Yep, looks good!