Large operation responses creates LOH memory cycling in .NET 4

Each operation response has its body copied from the network stream to a continuous memory buffer. Given that the maximum document size is 20GB, this means the maximum operation responses is slightly larger than 20GB (including headers and possibly some sub-doc operations like XATTRs).

The SDK makes an effort to reuse these buffers for subsequent responses. The buffers are rented from MemoryPool<byte>.Shared, which in turn is a wrapper for ArrayPool<byte>.Shared. When the buffers are disposed they are returned to the array pool for reuse (by the SDK or even by other parts of the application).

For .NET 6 and later this works great. However, prior to .NET 6 (such as .NET Framework 4) the ArrayPool<byte>.Shared has a maximum array length of 1MB. Any rental of 1MB or more is never reused upon return to the pool and is left for garbage collection. Given the size, this means it is resident on the Large Object Heap and part of Gen2 collection.

Note that this was changed in .NET 6 because of the addition of memory pressure handling. In .NET 4 there is no API available to detect the amount of memory pressure, but in .NET 6 there is so it can choose to discard large, infrequently used arrays from the pool when there is pressure. However, the 1MB limit is somewhat arbitrary. Most likely, we could operate our own pool for arrays up to slightly larger than 20MB safely. That said, it should probably be forwarded to the built-in pool for arrays <=1MB so that those can be shared with the rest of the application.