Use ArrayPool for oversized allocations

[benaadams]

When Pipelines allocation is larger than the max pool size; use ArrayPool, rather than new byte[]

Oversized allocations are useful in situations where you want to minimize syscalls; for example IHttpSendFileFeature in Kestrel its faster to read from a file directly into the Pipe (zero copy(ish)) with a larger buffer size (16kB+) than it is to read the smaller chunks the Pool allows, however if its allocating an array each time than this more than offsets that advantage.

Currently with the smaller block sizes it is more performant to read a file chunk first into a larger array pool buffer (lower syscalls), then copy that file into many smaller Pipe buffers.

It makes more sense to just read into the Pipe directly and avoid the additional copy.

It is unfortunate that this approach is currently slower; as you either have to increase file read calls using the smaller buffers, or allocate a new array for each read with a larger buffer.

This PR makes direct file reads into the Pipe a non-problematic option.

/cc @davidfowl @Tratcher @stephentoub

Resolves https://github.com/dotnet/corefx/issues/39640

[ahsonkhan]

Could _memoryOwner ever be anything else other than IMemoryOwner<byte> or byte[]?

[davidfowl]

Not anymore.

[Tratcher]

This will make dotnet/aspnetcore#12632 a lot harder.

[davidfowl]

Not really, we need need to expose an option to clear on return.

[Tratcher]

ArrayPool<byte>.Shared isn't usable if you always want to Rent cleared memory, you can't rely on everybody else to clear on return. You need an option to clear on Rent or you need a separate pool that's always cleared.

[davidfowl]

Sounds like a reason to do this https://github.com/dotnet/corefx/issues/25843