The WORM suite creates one bucket per test, each backed by ~3 reserved
volumes on the data node. With ~30 tests and the default `weed mini`
volume cap, the data node runs out of slots midway through the run and
every PutObject after that fails with InternalError.
Hook a sweep of every test-prefix bucket into the create helpers so a
panicked or interrupted prior test cannot leak buckets into the next.
This optimization avoids an expensive filer gRPC call for every DELETE
operation on buckets that don't have Object Lock enabled.
Before this change, enforceObjectLockProtections() would always call
getObjectEntry() to fetch object metadata to check for retention/legal
hold, even for buckets that never had Object Lock configured.
Changes:
1. Add early return in enforceObjectLockProtections() if bucket has no
Object Lock config or bucket doesn't exist
2. Add isObjectLockEnabled() helper function to check if a bucket has
Object Lock configured
3. Fix validateObjectLockHeaders() to check ObjectLockConfig instead of
just versioningEnabled - this ensures object-lock headers are properly
rejected on buckets without Object Lock enabled, which aligns with
AWS S3 semantics
4. Make bucket creation with Object Lock atomic - set Object Lock config
in the same CreateEntry call as bucket creation, preventing race
conditions where bucket exists without Object Lock enabled
5. Properly handle Object Lock setup failures during bucket creation -
if StoreObjectLockConfigurationInExtended fails, roll back the bucket
creation and return an error instead of leaving a bucket without
the requested Object Lock configuration
This significantly improves DELETE latency for non-Object-Lock buckets,
which is the common case (lockCheck time reduced from 1-10ms to ~1µs).
Chris Lu