Refactor PolarisMetaStoreManager interface into multiple interfaces

[collado-mike]

Description

PolarisMetaStoreManager is a monolithic interface that captures persistence, storage credential vending, remote cache, and grant management. This makes it easy to tie together many things that shouldn't be tied together - for example, the authorizer has dependencies on the cache types, so that it's impossible to make authorization pluggable using different grant rules.

This change strictly splits up the interface into multiple interfaces, but the single PolarisMetaStoreManager is still an extension of the others. Where it is possible to refer to specific interfaces, (e.g., the Resolver and the EntityCache), the references are changed, but we don't have factory types to generate realm-specific implementations of all interfaces and the PR was growing far too large when I started on that path.

Future PRs would update components to refer to specific interfaces and to break the tie between the PolarisMetaStoreManager interface and the others. The PolarisMetaStoreManagerImpl may continue to implement all interfaces.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Documentation update
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Interface only change - all existing tests continue to pass.

Test Configuration:

• Hardware:
• Toolchain:
• SDK:

Checklist:

Please delete options that are not relevant.

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• If adding new functionality, I have discussed my implementation with the community using the linked GitHub issue

[dimas-b]

LGTM overall 👍

[dennishuo]

LGTM, +1 to splitting. If the secrets manager will be specific to handling first-party auth, consider renaming it to PolarisPrincipalSecretsManager for clarity, or if it'll likely have some kinds of generic secret-management stuff for things like creating wrapped keys, encrypting/decrypting on the backend impl, then maybe better to leave it as you have it.

[dennishuo]

Once we have other types of stored secrets for outbound integrations/connections, we might have a different interface like "PolarisIntegrationSecretsManager" -- are you envisioning combining all different types of secrets into this interface, or would we split first-party principal auth-related management here (e.g. we might call this one PolarisPrincipalSecretsManager and keep it under this auth directory) from outbound integration secret management, possibly keeping PolarisIntegrationSecretsManager under the persistence directory?

[jbonofre]

If it's generally a good idea, do you mind to hold this for a few days ? The reason that it would break the current Quarkus branch. I'm proposing:

1. To open Quarkus draft PR to drive discussion/consensus
2. Review this PR after 1.
   Thoughts ?

[collado-mike]

If it's generally a good idea, do you mind to hold this for a few days ? The reason that it would break the current Quarkus branch. I'm proposing:

1. To open Quarkus draft PR to drive discussion/consensus
2. Review this PR after 1.
   Thoughts ?

Hey @jbonofre - I have a branch at https://github.com/jbonofre/polaris/compare/QUARKUS...collado-mike:polaris:patch-1?expand=1 that has this change merged into your Quarkus branch. The code compiles, though when I run the tests locally, it fails due to missing AWS_REGION branch.

Can we merge that change into your branch and move forward with this refactoring in main?