Patchable configuration files

[lynxplay]

The commit allows server administrators to define their changes to a paper configuration files via a patch yaml file, similar to how world configuration files patch the world defaults already.

The files can be specified via environment variables and are applied to the read config file after migrations.

Succeeds: #12834

---

Current open draft questions:

• Migration of patch files.
  As of right now, patch files are blindly applied to their targets without any checks by the server.
  While I don't think migration of their values is possible (or desirable, as it breaks the :ro usecase), this still poses a bit of danger to the server administrators using this feature. Specifically, a patch file might become outdated when we perform a migration on the main config file layout, resulting in the patch file changes to, at best, causes errors, at worst, be ignored.
  The server might then start up with potentially incorrect configurations, which might risk data and server integrity against users.
  My current thought on this is an optional version field in the patch files that, when specifies, causes the server to properly explode in case the patches target config version changes.
  This would then require a manual upgrade of the patch file but prevents the server from starting in a potentially incorrect state.

• Input of patches
  How to supply these patch files to the server has been a long standing point of question, not for the linked PR but mostly in the realm of "config presets" for, e.g., a vanilla configuration of paper. Environment variables are a must for containerized deployments of paper but might be a lot of effort for more simpler setups. Exploring alternative sourcing of config patches in addition to env vars is needed before this PR is ready for review.

• Patch targetting
  An alternative I think might be worth considering is, instead of using file names or env variables, we could use another _target yaml property or something and infer the target from there. That would unify the patch sources, e.g. a single folder would be enough when reading from disk.

[Leguan16]

Not quite the proposed feature but maybe worth noting that this could be related to #10484. not by adding the preset feature but by adding a way to easily applying "presets".

[NoahvdAa]

Perhaps we could read the config/patches directory in alphabetical order? Could be an easy way to allow config patching for people that don't want to use env vars

[lynxplay]

Yea just becomes a bit hard with targeting the patch file unless we want to move that into the patch file or have the file name require something. And such reading we'd definitely think about using this for vanilla presets as IIRC one idea was "just throw a sample configuration for vanilla values somewhere people can rename". So in this case, people could just rename paper-global-patch-vanilla.yml.off to paper-global-patch-vanilla.yml and enjoy their life.

[lynxplay]

An alternative I think might be worth considering is, instead of using file names or env variables, we could use another _target yaml property or something and infer the target from there. That would unify the patch sources, e.g. a single folder would be enough when reading from disk.

[Astralchroma]

Does this support other configuration files such as server.properties, bukkit.yml, and spigot.yml, and if not, could it be expanded to do such?

Alternatively does Paper intend to merge those config files in the near future?

[electronicboy]

This only supports config files using configurate, so not the legacy config files or the servers' built-in config. Merging the legacy configs into the paper configs is something I was hoping to do when we dropped the new config system out, but, that is planned; server.properties is likely unable to recieve this unless we rewrote how that is loaded

[Astralchroma]

My current thought on this is an optional version field in the patch files that, when specifies, causes the server to properly explode in case the patches target config version changes.
This would then require a manual upgrade of the patch file but prevents the server from starting in a potentially incorrect state.

This is probably the best option, however I would expand it by allowing patches to specify a "required" field with the options:

• "false" - If the patch is outdated, ignore it and move on, only a warning in the logs.
• "best_effort" - If the patch is outdated, apply parts of it where possible, only a warning in the logs if parts could not be applied.
• "true" - If the patch is outdated refuse to start the server. (Default)

[Astralchroma]

Merging the legacy configs into the paper configs is something I was hoping to do when we dropped the new config system out, but, that is planned

Understandable, is there anything in the works for that? If not is that something reserved for the Paper team or is anyone welcome to open a PR for it?

server.properties is likely unable to recieve this unless we rewrote how that is loaded

Fair enough, and honestly that one isn't as bad, it's relatively simple and doesn't change much, handles outdated files pretty well as is, and unlike all of the YAML config files, doesn't spam the console if it's read-only.