Feature: Allow client and server to negotiate on compression to use for the savegame

[ldpl]

Motivation / Problem

Client and server can be compiled with different sets of compression libraries. If client doesn't have the compression server uses it just fails. Also game uses lzma:2 for everything which isn't the best option for the network.

Description

Client on join sends bitset of all supported compressions to the server and lets the server to chose whichever it likes more. For that server has network.savegame_formats setting that allows specifying multiple compressions (space-separated) that will be tried in that order (if not specified it uses "zlib:2 lzma:0 lzo:0"). This also allows the server to use different compression methods for network connections and local saves.
In a way this is also a preparation for zstd inclusion (#8773) as otherwise it will have to use the older zstd version to support old platforms.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[JGRennison]

More generally, is it really necessary that the server operator is able to manually specify the algorithm order and levels?
Simply using the "correct" values for the current circumstances instead of allowing the user to specify an alternative set would probably make this simpler.
I can't imagine that the existing compression configuration field sees much, if any, use outside of testing.

[James103]

@JGRennison Some people still prefer to use a slightly larger but much faster savegame compression method (such as lzo instead of lzma) in order to reduce the CPU time required to save the game at the cost of some storage space.

Example: savegame_format = lzo can be up to 14x faster at the cost of only 1.75x the file size (as compared to zlib:6).

[ldpl]

@JGRennison My main reason was to allow disabling certain method if something goes wrong with it. Also wouldn't hurt for better DoS protection as it allows to disable slower or less efficient methods. And it doesn't rly make it simpler as it only saves a bit of parsing but requires some ifdefed constant or smth.

[ldpl]

Not that I'm completely happy with it but at least it looks decent now. Anyway I'm out of ideas for how to improve it so I guess it's ready for a review.

[glx22]

And I just noticed I had started a review, but never submitted it.

[TrueBrain]

As mentioned in #8773, this PR only has merit if there is more than one compression being offered that are useful. As there currently aren't, let's close this up for now, and reopen when we ever need it again.