Replace Lightbend Config with sconfig

[mdedetrich]

This PR replaces Lightbend Config with sconfig, for rationale please see discussion at #2186.

99% of the changes were entirely mechanical due to the fact that aside from the package, sconfig is entirely source compatible with lightbend config while also keeping the same behaviour. More specifically

• With regards to Java, aside from com.typesafe.config to org.ekrich.config the source code is 100% the same. That means for our Java users, if they ever programmatically used the typesafe config all they need to do is to change an import
• With regards to Scala, although sconfig is source compatible with lightbend config (again aside from com.typesafe.config to org.ekrich.config), newer versions of Scala have deprecated auto unary tupling and auto unary untupling, i.e ConfigFactory.empty vs ConfigFactory.empty() and v.valueType() vs v.valueType. Although we can technically make our Scala codebase compile without any changes of adding/removing (), this would involve suppressing deprecation warnings so I don't see any benefit in doing so.
• The migration steps outlined at https://github.com/ekrich/sconfig?tab=readme-ov-file#migrating-an-existing-lightbendconfig-project-to-sconfig worked perfectly (we didn't even need to add scalafix since Pekko project already has it) however one thing to note is that it only works for Scala source files, Java will need to be migrated separately but as said earlier the migration for Java is even easier (changing a single root package name). A single grep is all that Java users would need
• Most of the effort was actually in generating the MiMa filters, there was a lot of them....
• No tests need to be changed at all, everything just passed after the mechanical changes and the codebase was compiled. Even Pekko tests which were specifically testing for behaviour of Lightbend Config passed without changes
• The only non mechanical change needed was an update to the paradox doc apiMappings, this has been noted in the PR so its clear to see.

I still need to do a manual pass to check the documentation generation works fine (paradox compiled without issues but I will manually generate it locally to double check that the links to sconfig docs work as expected). Due to the large number of changes if you want to manually review the PR I would recommend checking out the branch and doing it locally.

To keep the discussions on topic, if you have questions on the premise of the PR (i.e. using sconfig in the first place) then please use the discussion thread at #2186. On the other hand if you have specific discussion regarding the implementation in this PR then feel free to comment

[mdedetrich]

This was the only non mechanical change needed, it was basically updating the apiMappings to point to the new online documentation for sconfig. Since sconfig is written in Scala we need to pass in the scala binary version to the doc URI

[mdedetrich]

@mkurz I know you were hesitant with this change but here is the PR with the changeset if you are curious on the difficulty/problems of doing such a change (with pekko so far there wasn't any problems at all)

[pjfanning]

Technically, this all seems fine. The main issue is that we need consensus on whether this change is needed.
The config jar is not causing us problems and we are not in need of new features.
The biggest win with sconfig is unblocking one issue on the path to supporting ScalaJS and/or Scala Native. It is not clear how much extra work there could be there in supporting cross-platform.

Even if we can persuade the sconfig team to have succession planning or possibly, setting up an ASF podling, this will take time.

[mdedetrich]

Technically, this all seems fine. The main issue is that we need consensus on whether this change is needed. The config jar is not causing us problems and we are not in need of new features. The biggest win with sconfig is unblocking one issue on the path to supporting ScalaJS and/or Scala Native. It is not clear how much extra work there could be there in supporting cross-platform.

Even if we can persuade the sconfig team to have succession planning or possibly, setting up an ASF podling, this will take time.

All valid points, lets continue discussing them at #2186. The primary purpose of making this PR now was to figure out how technically difficult it was (in reality not at all) and if there were any problems (none so far)

[He-Pin]

Waiting until all features is ready and battle tested, and still a vote pass.

And still a new version dropped the ccompat

[mdedetrich]

And still a new version dropped the ccompat

ccompat is a non issue as we already have ccompat in our code, its just manually inlined. This was done many many years ago before ccompat was even stable but thats no longer the case.

[He-Pin]

The cc module will be removed once 2.12 is removed.

[He-Pin]

I will follow @mkurz 's decision on this pr, if Play think we should stay , we should.

[mdedetrich]

So I have some good news, with the merge of ekrich/sconfig#488 on the next release of sconfig I can revert the ConfigObject.empty to ConfigObject.empty() change that I had to do this in this PR which will make the changeset smaller.

Turns out that having ConfigObejct.empty with empty parens was an oversight.

[He-Pin]

Does the sconfig fix all the pending issues in the lightbend/config ?