Commonalize RetroQuest configuration properties

[tsatam]

Summary

Unify all custom RetroQuest application configuration properties under the retroquest. namespace, with clear
domain-defined structure for properties and property groups.

Motivation

Currently, the configuration properties defined by RetroQuest are inconsistent in their name and purpose: some
properties are under com.retroquest., while others are under app. Some properties are not namespaced at all, for
example jwt.signing.secret used for signing the RetroQuest JWTs.

Current concerns

Complexity of deployments

For a deployer of RetroQuest, this becomes a burden to maintain. These properties are designed to be changed to suit the
conditions of a specific deployment, and are generally configured at once.

Difficult to add new properties

We are planning to add optional integrations between RetroQuest and other platforms. In order to facilitate this, we
would like to establish a clear structure for where these properties would go.

Design

• All properties MUST be namespaced under the retroquest. namespace.
• We will use YAML by default to handle the namespacing of properties.
• All properties SHOULD be read via @ConfigurationProperties beans, rather than through @Value annotations

With the current set of configuration properties, an example configuration file would look like this:

retroquest:
  integrations:
    captcha:
      enabled: false
      url: https://www.google.com/recaptcha/api/siteverify
      secret: ${random.value}
      failed-login-threshold: 5
  archive:
    thought:
      page-size: 30
  security:
    require-https: false
    jwt-signing-secret: ASLKJHDKJHikjsdkjhg1iu2heiIUGEIUQ@IUeiUIU@iyrgiu2g3i

spring:
  data:
    jpa:
      repositories:
        enabled: true
  jpa:
    hibernate:
      ddl-auto: validate
    open-in-view: false
    show-sql: false
  liquibase:
    change-log: db/changelog.xml

logging.level:
  root: warn
  com.ford.labs.retroquest: info

springdoc:
  packages-to-scan: com.ford.labs.retroquest

Benefits

• All RetroQuest properties are now under retroquest., eliminating any ambiguity around whether properties are part of
  Core Spring or other libraries, or part of RetroQuest
• Contributions to add new features such as integrations have a clear path forward as to where to define configuration

Drawbacks

Existing users of RetroQuest would need to update their deployment's configuration properties to account for this change

We should provide an application-legacy.yml that deployers can utilize to temporarily map the old configuration values
to the new expected locations.

Alternatives

Do nothing, maintain the current properties

This would continue the negative consequences we detailed above.

Plan

1. Refactor all existing properties to follow the outlined format
2. Convert existing application.properties to YAML and define all custom RetroQuest properties in it with "sensible"
   defaults (all integrations disabled)
3. Create an application-legacy.yml that maps the value of old properties to the new location