Description

The original file move implementation and its associated tests were rigidly structured around the assumptions and features of Hierarchical Namespace (HNS) enabled buckets. This constraint meant the functionality was unnecessarily restricted.

This change refactors the codebase to remove all explicit references, tags, and dependencies on HNS buckets throughout the move logic and testing stages. The goal is to make the move operation the standard implementation across all bucket types, specifically by:

1. Code Refactor: Eliminating HNS-specific checks and flags within the move logic.
2. Test Restructuring: Updating all integration and unit tests related to file moves to use normal (non-HNS) buckets by default, ensuring the logic is validated in the most widely used environment.
3. Standardization: Ensuring that the underlying copy-and-delete mechanism works seamlessly for standard buckets, achieving full compatibility.

Impact

This change significantly improves the compatibility and simplicity of the file move feature:

• The move operation is now standardized and fully functional for non-HNS buckets without requiring special flags or logic.
• It simplifies the codebase by removing domain-specific checks related to HNS.
• No breaking changes are introduced to the public API signature.

Testing

• Tests Restructured: All relevant unit and integration tests have been restructured to operate against normal (non-HNS) buckets to validate the core functionality in the default environment.
• Tests related to HNS-specific logic have been removed or generalized.
• The tests confirm that the file move operation now executes successfully in a standard bucket environment.
• No breaking changes are necessary.

Additional Information

This change shifts the assumed operational environment from HNS-specific to general-purpose buckets, simplifying future maintenance and development efforts. This ensures a clean, universal move API that performs correctly regardless of the bucket's HNS status.

Checklist

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease
• Appropriate docs were updated
• Appropriate comments were added, particularly in complex areas or places that require background
• No new warnings or issues will be generated from this change

Fixes #