What does this PR change? What problem does it solve?

Implement mitigation described in #5291 (comment)

However, there is a simpler option to push 2^21/k below 1 (and thereby break the attack). An attacker needs to be able to guess which chunks in a pack file belong to the attacker-known file and which sections of the file they correspond to. Restic currently sequentially assembles all fully processed chunks into a single pack file, which gets uploaded once it's full. To prevent an attacker to guess which chunks of a file are in a given pack file, restic can instead assemble two pack files in parallel and randomly assign chunks to those pack files. This should introduce uncertainty at least on the scale of a chunk size and thereby stop the information leak.

There's one corner case that has to be considered here. A user could backup only a small file that get's split into two chunks. If those end up in individual packs, this would again leak the chunk size. Thus, if two small pack files remain in the end, then those must be merged.

Was the change previously discussed in an issue or on the forum?

See #5291 (comment)

Checklist

• I have added tests for all code changes.
• I have added documentation for relevant changes (in the manual).
• There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
• I'm done! This pull request is ready for review.