HTTP storage protocol design change: switch all secrets to http headers

[itamarst]

Secrets include:

1. The new upload secret (#3820).
2. Write secrets for mutables.
3. Lease renewal/cancellation.
4. Arguably, storage index, although that's more open to discussion.

These secrets should not be leaked by accident.

The current system puts them in the body of requests, which mean request logging is more likely to leak them.

HTTP headers are the standard way of passing credentials, and logging them is less common than URLs or bodies. So perhaps we should switch to using them for all of the above.

[itamarst]

ccx points out that potentially one could separate the syntax for "here is the secret you should use" vs. "here is me authorizing myself with a secret". For example, the first usage might be in the POST/PUT body and the second as a HTTP header.

This semantic distinction between providing a new secret and authenticating with a secret is present for leases, and in #3820 it is present for immutable uploads. The mutable upload API does not have this distinction, it's one API call for creating and subsequent modifying.

[itamarst]

Jean-Paul suggests that storage index logging should be avoided, but is not fundamentally a problem:

1. Storage indexes are already not particularly secret. The client will tell approximately ~every storage server it can find about your storage indexes.
2. Knowing a storage index buys you very little. You can obtain some ciphertext that you cannot decrypt.
3. A premise of Tahoe is that you only rely on storage servers to return your ciphertext to you later on. You are _not_ relying on them to not make your ciphertext public.

[GitHub <noreply@…>]

In fe6a2f6f/trunk:

Merge pull request #1146 from tahoe-lafs/3820.gbs-immutable-upload-session

Use an upload secret for GBS immutable uploads

Fixes ticket:3820
Fixes ticket:3826