CopyObject with retention does not work as expected

[halkyon]

Goal

CopyObject without specifying retention settings should not copy any settings from the source object. We seem to be copying across lock settings to the destination object which misleads the user into thinking locks were copied. However, the lock on the destination is not enforced, which is correct. I think this may be because object lock settings are stored in object metadata, and CopyObjectHandler in minio blindly copies over all the metadata to the destination. Quite possibly this line here is causing the trouble and isn't filtering out the metadata (https://github.com/storj/minio/blob/main/cmd/object-handlers.go#L1197):

srcInfo.UserDefined = objectlock.FilterObjectLockMetadata(srcInfo.UserDefined, true, true)

When you do specify retention settings on CopyObject, then it fails with an InvalidRequest: Bucket is missing ObjectLockConfiguration error, even if the bucket has locking enabled. Minio has code to check if locking is enabled on the bucket, but this only checks a global minio-specific flag for the bucket: https://github.com/storj/minio/blob/main/cmd/bucket-object-lock.go#L266. Do we still need all the validation here? One idea might be to remove checkPutObjectLockAllowed and not call it from CopyObjectHandler so our object layer does the validation instead.

Acceptance Criteria

• CopyObject without retention settings does not copy lock information across to the destination of any kind, including metadata. Get/Head Object calls on the destination do not show any lock mode or retain date.
• CopyObject with retention settings sets lock correctly on the destination and locking is enforced. The copied version with lock cannot be deleted.

[storj-gerrit[bot]]

Change pkg/bucket/object/lock: fix lock settings copied incorrectly mentions this issue.

[storj-gerrit[bot]]

Change cmd: remove global lock setting checks for CopyObjectHandler mentions this issue.