SignatureDoesNotMatch issue with s3-presign

I've been working on a self-hostable Logseq Sync backend, and I was having trouble with the issued STS credentials. The flow looked like:

1. Client calls /get_temp_credentials
2. Server issues new credentials via STS, scoped to just the /temp:<region>/<random uuid> bucket prefix
3. Client generates presigned URLs to PUT files to
4. Uploads fail with SignatureDoesNotMatch

But I noticed it wasn't failing all the time! One out of every ten or twenty tries would succeed, indicating it wasn't some complete misconfiguration. There are many, many threads about the SignatureDoesNotMatch issue (here's a big one), some are user error, but many seemed to be resolved by regenerating credentials with no /, +, or = in the secret, but I tried that, and the same issue happened.

So to continue debugging, I did a few things:

• I wrote a quick tool that uses the credentials I was generating (via /get_temp_credentials), and generates signed PUT URLs, then uploads files to them. That worked fine, indicating that the credentials aren't the problem
• I swapped out the existing, bespoke s3-presign crate with durch/rust-s3, to see if that was the issue, you can see the relevant changes here.

And the swap worked, my local hacked up Logseq client can now reliably upload files with the presigned S3 URLs it generates with the short-lived STS credentials:

15:26:32.398 › update remote files[txid=1]: ["journals/2023_11_25.md", "pages/This is a test.md"]
15:26:32.626 › upload progress: 100% 360/360 journals/2023_11_25.md
15:26:32.627 › upload progress: 100% 304/304 pages/This is a test.md
15:26:33.758 › copy page file to version-files: "journals/2023_11_25.md"
15:26:33.759 › copy page file to version-files: "pages/This is a test.md"
15:26:33.759 › update remote files success, txid=2

So I'm pretty confident the issue is with the s3-presign package. I don't know what the official Logseq Sync server implementation does (likely during STS credential generation?) such that this issue doesn't occur, but it seems there's some edge case that causes it to generate invalid signatures.

Start with the bespoke s3-presign package and the presigning call in sync/src/sync.rs around lines 394-425. Use cmd/tools/signtest to compare its signed PUT URLs with those produced by durch/rust-s3, using the short-lived STS credentials. Done means uploads reliably succeed without SignatureDoesNotMatch, as they do with the replacement implementation.