Improve chunking strategy for tables with the composite PK

[kamil-holubicki]

This PR addresses two issues:

Issue 1 (the big one):

PS-10413: Improve chunking strategy for tables with the composite PK

https://perconadev.atlassian.net/browse/PS-10413

Introduced an enhanced chunking algorithm.

Problem:
The original algorithm consider only 1st column of the primary key when
chunking the table for parallel dump. If the table contains
the composite PK it may happen that there is a huge amount of rows for
a given key part.
As the result, chunk sizes are not well-balanced.
Dumping process is delegated to parallel workers. Each chunk is dumped
by the separate thread. If there is a huge chunk and multiple small
chunks, all small chunks will be quickly processed in parallel, but
the huge one will use a thread for a long time, while other worker
threads are idle.

Solution:
Implemented chunking algorithms that uses other key parts to produce
table chunks.

Chunking Algorithm Overview

The chunking mechanism divides large table into manageable chunks to
enable parallel data extraction and optimal memory usage.
The algorithm supports two strategies:
ORIGINAL and ENHANCED. ORIGINAL is the default behavior of mysqlsh.

Integer Column Chunking:

For numeric primary keys (INTEGER, UNSIGNED INTEGER, DECIMAL):
Phase 1: Range Expansion (Linear)**

• Starts with an estimated step size based on:
  index_range / estimated_chunks
• Expands the search range until enough rows are found
  (rows >= rows_per_chunk)
• Stops if maximum range is reached or sufficient rows are found
  Phase 2: Binary Search (Shrinking)**
• If too many rows are found (rows > rows_per_chunk + accuracy)
• Uses binary search to narrow the range to match target row count
• Continues until: delta <= accuracy OR range shrinks to 1
• Falls back to nested chunking if single value still exceeds row limit

Nested Chunking (Deep Chunking):

When a single value in the current key part exceeds rows_per_chunk:

• Recursively chunks the next key part with boundary condition
• Only applies if next column is optimizable (INT-like type)

Chunk Gluing (ENHANCED strategy only):

The Gluer class merges small chunks to optimize dump file count:

• Accumulates consecutive chunks when row count < max_rows_cnt
• Flushes when accumulated size > 3 * max_rows_cnt or at table end
• Prevents fragmentation by combining undersized chunks
• DummyGluer (for ORIGINAL) disables this optimization

Introduced dump configuration options:

adaptiveStepStrategy - strategy used for determining chunk boundaries
original - Default. Use the original implementation
enhanced - Use the new approach for calculations

maxKeyPrefixLength - limits the number of key parts used for chunking
(depth)
0 - Use the whole length of the key (up not compatible column)
Default: 1 to keep the original behavior

Isse 2 (the small one):

PS-10416: Calculate and send checksum header for uploads to support S3 Object Lock

https://perconadev.atlassian.net/browse/PS-10416

Object Lock feature of the AWS S3 requires Content-MD5 request header
to be present in the PUT request.

Added calculation of this header. It is calculated always, as it
simplifies the logic and does not cause any harm even if not needed.

[mysql-oca-bot]

Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment:
"I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it."
Thanks