b2: Add optional secondary key for locks

[ongardie]

This enables a configuration that prevents restic from deleting its own files.
See the explanation in doc/030_preparing_a_new_repo.rst

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

This enables a configuration that prevents restic on Backblaze B2 from deleting its own files (either by mistake or as the result of a key compromise). It allows the user to configure two B2 keys: one can read and write but not delete files, and the other can read+write+delete but only under the locks/ directory.

An alternative implementation approach would be to allow two entire backends: one used for most files and the second used only for locks. This would be more general and may enable other useful configurations, but it seems significantly harder for the user to set up.

Was the change discussed in an issue or in the forum before?

I haven't open any discussions before. This is related to and probably conflicts with #2398.

Here's a related discussion for Wasabi, which seems to support finer-grained access policies: https://forum.restic.net/t/append-only-mode-with-s3-wasabi/845. As far as I can tell, Backblaze only allows a coarse list of permissions per key.

Checklist

• I have read the Contribution Guidelines
• I have enabled maintainer edits for this PR
• I have added tests for all changes in this PR
• I have added documentation for the changes (in the manual)
• There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
• I have run gofmt on the code in all commits
• All commit messages are formatted in the same style as the other commits in the repo
• I'm done, this Pull Request is ready for review

[PriceChild]

Related: #2134

[MichaelEischer]

Thanks for suggesting a new feature. However, the necessary setup feels rather convoluted. As files can still be overwritten I don't see a benefit compared to #2398. And a proper solution using Object Locks will also work better with the latter PR. Thus, I'll close this PR, sorry for taking so long to reach a decision.

[ongardie]

Thanks for the follow-up @MichaelEischer. I haven't followed #2398 closely, but I agree it looks like a more promising direction.