Add http/1 response streaming to Canvas batches

[chrisdavies]

This adds response streaming to Canvas batch requests. The response streaming logic itself is in a standalone UI folder so that it can be reused elsewhere (the plan is to use it in a courier replacement.

This allows canvas batches to process batch responses as they come in, rather than waiting for the entire batch to complete, and should theoretically make the UI feel more responsive. The main purpose of this work is to facilitate a courier replacement effort that is in progress. So, if we don't want to add this to Canvas itself, we can simply use this as a reference PR for that courier work, and not merge this.

The branch name (kfetch/streaming) is misleading, as this doesn't modify kfetch. I started out implementing this as a kfetch modification, but it turned out to be the wrong approach, and a conversation with the kfetch implementors suggested this would be better as a standalone piece.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[chrisdavies]

I wonder, for large payloads, if the frequent reading of the response text will cause this to be slower / much worse than not streaming in the first place. It'd be nice to put this through some perf tests.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[w33ble]

I wonder, for large payloads, if the frequent reading of the response text will cause this to be slower / much worse than not streaming in the first place. It'd be nice to put this through some perf tests.

Sample size of one, with a single workpad, so take this with a grain of salt, but this is what I see:

Branch	Load time	Refresh time	Requests to fns
pull/31958	~ 4 seconds	~3 seconds	4
This PR (rebased on pull/31958)	~ 4 seconds	~3 seconds	4

Timing is just manual using the stopwatch on my phone with devtools closed

So in practice, this doesn't really seem to change much of anything, but at the very least, it doesn't seem to slow things down. And I agree that having real perf checks would be great.

[w33ble]

Changes look good, functionality looks good. I thought I found a bug in the batching, but when I wrote some tests locally I was wrong. All in all, this LGTM.