Improvements to PolarisConfiguration

[eric-maynard]

Description

I've had a hard time working with PolarisConfiguration and ran into various casting issues during testing. Before we have too many configurations, let's impose some structure on these and make it easier to get values out of configs.

I've also unified the catalog-level and service-level configs here, and added a description for each config.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• 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
• Refactor

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
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes

[flyrain]

LGTM overall. Some questions:

Do we consider reusing other libs like Apache Common Configuration, or Lombok(need Spring)? For exmaple, we don't have to write our own type casting, the former can convert data type as the following code shows.

Configuration config = configs.properties("config.properties");

            // Convert to different data types
            String appName = config.getString("app.name");
            int port = config.getInt("app.port");
            boolean isActive = config.getBoolean("app.active");
            double timeout = config.getDouble("app.timeout");

Lombok is even simpler with less code. I know it has to combine with spring boot, but considering a lot of benefits it brings as well as great eco system around spring. It's worth to explore.

[eric-maynard]

Looks good @flyrain, I think we should continue to think about this. For one thing, I want to make sure we have a way to surface these in the docs. I'd be open to adding a library here, but I thought it would be wise to incrementally improve this.

wrt casting I believe our current setup is supposed to not require casting, but when you override DropWizard configs like this test does the value does not cast from String to Boolean correctly. I added the tryCast method as a way to brute-force the correct type for now. Hopefully if we migrate to using some framework that will go away.

[snazy]

The actually most advanced config library I've seen is smallrye-config.
We already have code (in Nessie) that converts javadoc from smallrye-config configuration interfaces into markdown.