feat: Default Settings Repository

[SychO9]

Fixes #3056
Needed for #3011

Changes proposed in this pull request:

• Introduces a default settings extender to register setting default values.
• Deprecates the addSettings migration helper.

Reviewers should focus on:
I don't think we're missing anything about us switching to this approach ?

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

[askvortsov1]

Radical idea, but alongside this, I think we should consider deprecating the default arguments to get settings. Otherwise, those arguments take on a weird hybrid role between truly being a setting default, and representing "if setting is null, do X". The latter isn't nonsensical, but it can also be done explicitly.

On the other hand, maybe there could be theoretical use cases for overriding the default on individual call sites, although I can't really think of any. But keeping defaults to one place would definitely simplify things.

[askvortsov1]

Looking over this again, there's still one thing I'm unsure about.

There's a difference between a setting not being set (in which case default should be used), and a setting having the value of null (in which case null should be returned). Ideally, our system should be able to distinguish between the two, but because of the current implementation with nullable defaults, the difference between the two is encapsulated within get and not available to the caller. In this PR, you pass the configured default value through the repo layers, which solves the problem, but depends on the default argument that we are hoping to remove.

For v2, when we do remove the argument, we could throw an exception in DatabaseSettingsRepository if the setting is not found. This doesn't depend on the default arg, so it fits well with our plans. It would be a breaking change though, which is why we can't do it now.

[SychO9]

There's a difference between a setting not being set (in which case default should be used), and a setting having the value of null (in which case null should be returned). Ideally, our system should be able to distinguish between the two, but because of the current implementation with nullable defaults, the difference between the two is encapsulated within get and not available to the caller. In this PR, you pass the configured default value through the repo layers, which solves the problem, but depends on the default argument that we are hoping to remove.

Good point! hadn't thought of that, and agree with the plan for 2.0

[askvortsov1]

This is really nice now!