CAS GC: cut batch deletes to the storage's batch-delete limit

[filimonov]

CAS GC sent a write-once delete cohort (up to cas_gc_bulk_delete_chunk_keys, 1000 keys) as one request, ignoring objects_chunk_size_to_delete on S3 and the one-key limit of a storage without DeleteObjects. GC now cuts each cohort into requests of the storage's batch-delete limit. The S3 delete paths also keep the store's error name in S3Exception.

Changes

• IObjectStorage::batchDeleteKeyLimit (default 1). S3ObjectStorage returns objects_chunk_size_to_delete, or 1 once DeleteObjects is known unsupported.
• Cas::Backend::bulkDeleteKeyLimit, forwarded by every decorator; kBulkDeleteMaxKeys for the in-memory and the emulated backend.
• Gc::bulkDeleteChunkKeys is the smaller of the setting and that limit. The manifest_deletes phase and cleanupRefObjects cut a cohort into requests of that size through the existing removeChunkWriteOnceOrOneByOne. The cohort, its budget accounting and the one authorityHolds read per cohort are unchanged.
• S3ObjectStorage::removeObjectsIfExistImpl and deleteFileFromS3 pass the store's error name into S3Exception: isRefreshableCredentialError recognises errors the SDK does not model only by getExceptionName.

Risks / notes

• Touches shared code outside CAS: one virtual method in IObjectStorage.h, one override and two throw sites in S3ObjectStorage.cpp, one throw site in src/IO/S3/deleteFileFromS3.cpp. The exception type and message are the same; only the name is added.
• A disk with objects_chunk_size_to_delete below 1000 now gets more, smaller DeleteObjects requests from GC phases 15 and 17.
• The namespace janitor of CAS GC: batch the namespace janitor's deletes under a soft time budget #2483 does not use this limit yet. That needs both PRs in the base and comes as a follow-up.
• No on-S3 format change.

Testing

• Unit: CAS* gate, debug and ASan. New: CASBulkDeleteBackend limit forwarding and clamping (5 tests), CASGCManifestBulkDelete.StorageLimitCutsTheCohortIntoRequestsOfAtMostThatManyKeys, CASRefGc.RefObjectCleanupCutsRequestsToTheStorageLimitWithoutExtraAuthorityReads, CASS3BatchDelete (the S3 limit; error names for a whole-request error and for a per-key error in a 200 reply). With bulkDeleteChunkKeys ignoring the backend limit, both GC-level tests and two CASBulkDeleteBackend tests fail.
• Not done: the CASS3BatchDelete error-name test was not run against the old throw sites; no integration run on RustFS or S3.

Related: #2483
Related: #2468

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

CAS GC batch deletes respect the storage's batch-delete limit (objects_chunk_size_to_delete on S3), and S3 delete errors keep the store's error name.

Documentation entry for user-facing changes

• Documentation written in this PR (docs/en/antalya/cas/configuration.md)

CI/CD Options

Regression jobs to run:

• CAS (content-addressed storage; Antalya only)

[github-actions]

Workflow [PR], commit [7946c7c]