Remove HTTP content copies

[mhl-b]

Remove HTTP content copies entirely from REST handlers. All handlers from now should use RefCounted pooled byte buffers. Handlers that parse x-content in prepareRequest by default will use pooled buffers. Other handlers that move pooled buffer to another thread should use new method ActionListener.withRef(listener, content) for proper reference counting.

In current implementation of ActionListener.withRef buffers are retained till we have a response. It is not optimal since buffers can be released once request is dispatched in transport. But in reality the performance implication might be negligible. Ideally we should bind buffer lifetime to the transport request, not to results listener. But it's a larger code change. For example BytesTransportRequest implements explicit ref counting for the content.

For example:

- return channel -> client.index(indexRequest, new RestToXContentListener<>(channel));
+ return channel -> client.index(indexRequest, ActionListener.withRef(new RestToXContentListener<>(channel), content));

Follow-up for #116115

Closes ES-10140

[elasticsearchmachine]

Hi @mhl-b, I've created a changelog YAML for you.

[elasticsearchmachine]

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

[DaveCTurner]

LGTM

[DaveCTurner]

This is ok but it looks like we only use org.elasticsearch.action.admin.cluster.storedscripts.PutStoredScriptRequest#content in order to validate its length, we should replace it with a number.

[DaveCTurner]

Actually it's still used in toString(), but not particularly usefully IMO, so I opened #117556 to remove that (and clean things up in this area too). Once that's backported to 8.18 we can safely replace this with a number in 9.0.

[DaveCTurner]

I thought this wasn't correct, it looked like we end up putting the source in the cluster state, so it seemed that we need to take a copy. But now that I look closer I see that org.elasticsearch.ingest.PipelineConfiguration#PipelineConfiguration(java.lang.String, org.elasticsearch.common.bytes.BytesReference, org.elasticsearch.xcontent.XContentType) parses the source to a map and stores that. So this seems ok to me.