I notice that we are using a -C flag here for hocon. Isn't this deprecated ?

This is returning Unit so clearly doing some 'nasty' mutation of the parser. A comment as to its intended use may help.

LegacyAuthServiceConfigCli maybe ?

We need to work on postgres and oracle so it looks strange to have a field called postgres.

This object is mapped by pureconfig library as is currently, so it produces the following config in hocon format:

        database {
          connection-pool {
            connection-timeout = "250ms"
            max-pool-size = 17
            minimum-idle = 17
          }
          jdbc-url = "jdbc:h2:mem:default;db_close_delay=-1;db_close_on_exit=false"
          postgres {
            synchronous-commit = off
            tcp-keepalives-count = 5
            tcp-keepalives-idle = 10
            tcp-keepalives-interval = 1
          }
        }

How about making it Option[PostgresDataSourceConfig] so it can be undefined?

Maybe it should be dataSourceconfig: DataSourceConfig with variants for Postgres/Oracle. I don't understand why we would need specific config for one DB but not another (in the general case).

I tend to not use polymorphic objects within configuration as it adds complexity on parsing, deriving and understanding of the concrete type used to map for this path - this is why it is within postgres path - you know exactly what are the possible values and their types. In case of generic "data-source-config" path and interface used to map for this path - how would parser know which config type to use here? Usually type hint is used in this case, but not sure I would like something like:

database {
  jdbc-url = "jdbc:h2:mem:default;db_close_delay=-1;db_close_on_exit=false"
  datasource-config {
    type = postgres
    synchronous-commit = off
    tcp-keepalives-count = 5
    tcp-keepalives-idle = 10
    tcp-keepalives-interval = 1
  }
}

Let me investigate further if there is a better way for that. I might come with another proposal.

How many of these conformance tests get run on each PR to main. How long does it add to the build ?

I have added them to make sure HOCON configuration works just like old CLI. In fact did not plan them to be in parallel and they should have been replacing old cli implementation. Let's agree first on the sequence of work merged to main and deprecation policy, it would be then clear what to do with the tests.

LegacyBridgeConfigProvider maybe ?