Update ACR UploadBlob method to upload a blob in chunks

[annelo-msft]

Fixes #32339

The current implementation of ContainerRegistryBlobClient.UploadBlob() tries to upload an artifact layer in a single chunk, and if the layer size is large, that can cause the service to close the connection during upload, and the upload to fail.

This PR reimplements UploadBlob() to upload the layer in chunks, and optionally allows the caller to specify the chunk size.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

Azure.Containers.ContainerRegistry

[pallavit]

public partial class ContainerRegistryBlobClient

This is also a perfect client candidate for perf testing for the SDK.

---

Refers to: sdk/containerregistry/Azure.Containers.ContainerRegistry/api/Azure.Containers.ContainerRegistry.netstandard2.0.cs:230 in 2cda954. [](commit_id = 2cda954, deletion_comment = False)

[JoshLove-msft]

Can you point me to more information about not buffering the stream? Is this something we've typically done in other libraries for large files?

By buffering the stream, I mean reading the whole stream into a memory stream. I could see how this could cause OOM issues. But we weren't doing this in the previous implementation, so I was curious where the memory issue was actually occurring. I would imagine it is probably in the transport layer if the transport ends up attempting to send a single request.

[annelo-msft]

This is also a perfect client candidate for perf testing for the SDK.

@pallavit, tracking with #32415

[annelo-msft]

By buffering the stream, I mean reading the whole stream into a memory stream. I could see how this could cause OOM issues. But we weren't doing this in the previous implementation, so I was curious where the memory issue was actually occurring. I would imagine it is probably in the transport layer if the transport ends up attempting to send a single request.

I still haven't heard back from the service team on this, but looking at the information they've given us, it looks like the OOM issue they were experience was on download of a large blob. The only thing I've been able to repro on upload is the service closing the connection, presumably because we're sending too much data/data too slowly:

----> System.Net.Http.HttpRequestException : Error while copying content to a stream.
----> System.IO.IOException : Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host..
----> System.Net.Sockets.SocketException : An existing connection was forcibly closed by the remote host.

Uploading in smaller chunks does mitigate this.

I'll update the PR description to more accurately reflect the issue as well - thanks, @JoshLove-msft!

[annelo-msft]

Ingestion is going to use an ArrayPool (which is better for large amounts of data): https://learn.microsoft.com/en-us/dotnet/api/system.buffers.arraypool-1?view=net-6.0. Maybe that would work here as well? :)

@nisha-bhatia, I plan to re-work the implementation to possibly use ArrayPool when I implement chunked/parallel download. Thanks again for the suggestion!