The version in hf_xet/Cargo.lock was not updated in the current main/

This PR implements incremental progress reporting on the upload_xorb
function, reporting progress every 512KB of data uploaded.

In addition, errors are retried using the same retry policy as the other
clients. To get around Body::wrap_stream preventing retries due to
cloning failing, this PR adds a simple retry wrapper utility that allows
the entire request to be retried instead of doing it as part of the
middleware layer.

With deduplication, just tracking the total processed bytes can give a
false impression of actual progress when uploading files; the user would
often see a huge jump when hitting a deduplicated part. This PR allows
us to report bytes uploaded or downloaded separately from the bytes
processed, which would allow us to correctly surface network
utilization.

For example, one possible way to show this would be:  

```
Data Processed      #####################╺━━━━━━━━━━━━━━━━  58% • 1.8/3.1 GB     • 731.6 MB/s • 0:00:10
New Data Uploaded   ######╸━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━   9% • 65.9/731.7 MB  • 131.0 MB/s         • -:--:--
data_up/d2.dat      #############################╸━━━━━━━━  67% • 67.1/100.0 MB  • 568.1 MB/s • 0:00:01
```

With the current incremental progress updates, the amount of updates
going to python is substantial, and each has to acquire a global GIL
lock. This negatively affects the upload speed on fast connections.

This PR introduces an intermediate aggregation class that quickly
aggregates all the incoming progress updates, then sends the aggregated
update list to hf_xet once every 200 ms. With this, the thread
contention experienced by the frequent incremental updates is eliminated
while still reporting accurate progress to the user.

Co-authored-by: Brian Ronan <brian.ronan@huggingface.co>