Ship brotli level 11 precompressed assets as part of the release archive

[!TIP]

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

Is your feature request related to a problem? Please describe.

Currently the release archive only contains the raw uncompressed assets (js/css/etc) which are transmitted in theier full sizes to the clients. This can be improved by compressing them on the fly by the webserver, but this has two downsides: 1. there is no caching, so every request takes more cpu to compress the response and 2. to be still fast enough a lower level of compression is required, so assests are not as small as they could be. The best option would be to precompress the assests so that they only need to be compressed once and can use the highest level of compression. After doing some tests (brotli vs zstd vs gzip) the best result in compression ratio and browser compatibility goes to brotli. But currently precompressing the assests myself using brotli level 11 will break the integrity check.

Describe the solution you'd like

Because of this it would be great to see one of these four things:

1. Precompress all shipped js, mjs, css, html, svg and ico files with brotli on the highest level (11) and include them in the release archive. (with adjusted htaccess+nginx docu)
2. The same but provide two release archives one with only uncompressed ones and one with uncompressed+brotli files (with diffrent htaccess+nginx docu or explain addiotnal apache configuration+nginx docu)
3. Do not include the precompressed brotli files in any archive, but the integrity check uncomresses them and checks against the original files so that users can precompress the files themself without breaking the integrity check.
4. Do not include the precompressed brotli files in any archive, but save theier signature in the integrity dataset only so that users can precompress the files themself without breaking the integrity check. (since the brotli output is should always be the same this should work, but I'm not sure)

Describe alternatives you've considered

Exclude .br (or maybe also gz and zst) files from the integrity check, but this would allow modifying these files which are send to the browsers without the check noticing it. Or keep dynamic compression.

Additional context

see https://github.com/nextcloud/all-in-one/pull/8521 and https://github.com/nextcloud/all-in-one/pull/8557

Start by reviewing how the release archive is generated and how the integrity check handles shipped assets. Compare the proposed archive options with the linked pull requests, then determine the required .htaccess and nginx documentation changes. Done means one approach is selected, implemented consistently, and verified for archive contents, integrity checking, and webserver configuration.