Keep config and schema unchanged during a release

[stefanhaller]

Some of our documentation is auto-generated from the source code (the defaults section in Config.md, and the keybinding cheat sheets), and so is the JSON schema for the config file. We have a check running on CI that verifies that when the source code changes (e.g. a new config option is added), those files are properly regenerated, to make sure they are always up to date with the latest version of the source code.

This causes a problem when people look at the documentation for a newly added config option and wonder why it doesn't work in the lazygit version they are using. Lots of issues were filed where people report this as a bug, and we have to patiently explain to them that the documentation describes a feature that hasn't been released yet. A similar problem occurs when we rename a config option (as has recently happened with the 'paging' config, which was renamed to 'pagers' in #4953), in which case the user's editor (if it supports JSON validation against the jsonschema store) starts to complain about the old config, even though it still works, and the new one doesn't yet.

To solve this, keep the documentation and the JSON schema unchanged for the lifetime of a release; make those continuous changes in a separate copy of those folders, and only copy the files back to the real location right before we make a release. To facilitate this, we add a script to conveniently create a PR for copying the files back, and add a check to the release workflow to abort with an error if this was forgotten.

Note that we only use this approach in order to solve the problem with the auto-generated files; this has a consequence for making changes to the other, non-auto-generated parts of the docs. For example, when fixing a spelling error, rewording a paragraph to explain it better, or adding an entirely new file, those changes will now have to be made in docs-master, which means:

1. if we forget this and make the change in docs accidentally, it will be reverted with the next release.
2. if we do remember to make the change in docs-master, it will take until the next release for it to be visible to users.

We can mitigate 2. by making the identical change in both places, but I think we should first wait and see how often it happens, and whether it is actually a problem.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 42e42321	✅ 0.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (42e4232)	Report Missing	Report Missing	Report Missing
Head commit (6ab40df)	58880	51211	86.98%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#5010)	1	0	0.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩