s3 workspace_key_prefix

[jbardin]

The handling of slashes was broken around listing workspaces in
workspace_key_prefix. While it worked in most places by splitting an
extra time around the spurious slashes, it failed in the case that the
prefix ended with a slash of its own.

A test was temporarily added to verify that the backend now works with the
unusual keys, but rather than risking silent breakage around prefixes
with trailing slashes, we also add validation to prevent users from
entering keys with trailing slashes at all.

--- PASS: TestBackend_impl (0.00s)
--- PASS: TestBackendConfig (1.08s)
--- PASS: TestBackendConfig_invalidKey (0.00s)
--- PASS: TestBackend (18.43s)
--- PASS: TestBackendLocked (27.05s)
--- PASS: TestBackendExtraPaths (16.82s)
--- PASS: TestBackendPrefixInWorkspace (6.02s)
--- PASS: TestKeyEnv (58.52s)
--- PASS: TestRemoteClient_impl (0.00s)
--- PASS: TestRemoteClient (6.58s)
--- PASS: TestRemoteClientLocks (19.80s)
--- PASS: TestForceUnlock (18.84s)
--- PASS: TestRemoteClient_clientMD5 (14.00s)
--- PASS: TestRemoteClient_stateChecksum (21.14s)

related to #17508

[apparentlymart]

LGTM! 👍

It seems like technically this a breaking change for anyone who was using leading/trailing slashes in a way that managed to work before in spite of being incorrect? I think that's okay if so -- we're about to do a major release anyway -- but would warrant a "Backward Incompatibilities / Notes" entry in the changelog, perhaps.

[jbardin]

Yup. I purposely made the validation change in order to force it to show up for users, in case there was yet still missing some edge case around the slashes and splits that wasn't covered yet.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.