Replace MAX_KEYS_PER_DELETE constant with function

[arpad-m]

Azure has a different per-request limit of 256 items for bulk deletion compared to the number of 1000 on AWS. Therefore, we need to support multiple values. Due to GenericRemoteStorage, we can't add an associated constant, but it has to be a function.

The PR replaces the MAX_KEYS_PER_DELETE constant with a function of the same name, implemented on both the RemoteStorage trait as well as on GenericRemoteStorage.

The value serves as hint of how many objects to pass to the delete_objects function.

Reading:

• https://learn.microsoft.com/en-us/rest/api/storageservices/blob-batch
• https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteObjects.html

Part of #7931

[github-actions]

7051 tests run: 6726 passed, 0 failed, 325 skipped (full report)

---

Flaky tests (8)

Postgres 17

• test_physical_replication_config_mismatch_max_locks_per_transaction: release-x86-64
• test_tenant_delete_smoke: release-arm64

Postgres 16

• test_prefetch[None]: release-arm64

Postgres 15

• test_prefetch[4]: release-x86-64
• test_scrubber_physical_gc_ancestors[2]: release-arm64
• test_pull_timeline[True]: release-arm64

Postgres 14

• test_prefetch[4]: release-x86-64
• test_pull_timeline[True]: release-x86-64

Code coverage* (full report)

• functions: 31.4% (8336 of 26534 functions)
• lines: 47.7% (65569 of 137388 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
822494f at 2024-12-09T17:41:25.443Z :recycle:}

[erikgrinaker]

Seem fine as a targeted fix.

In general, I think it'd be better to hide this as an implementation detail. For example by having a method that deletes objects from an iterator, handling the batching internally.

[arpad-m]

I think such an API wold be more complicated and not a good idea. We also want to avoid having remote_storage do retries itself as much as possible.