Consume fetch stream output in tests

[GregoryTravis]

This does not solve the problem behind #11878, but it does consume the stream and close it, so that the problem is not triggered in CI. The problem is not consistently reproducible since it relies on cache size pressure.

Closes #11879.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[radeusgd]

This does not solve the problem behind #11878

Should it then close that ticket? If we close it, shall we create a new ticket to track the remaining issue?

Oh sorry, ignore my comment - I realize now these are 2 different tickets, their numbers were so close that I missed that - perhaps not enough coffee today 😅

[radeusgd]

Yeah, the internal methods were made with assumption that their result will always be consumed. Perhaps that assumption is a bit too trusting on the consumer, so we may want to revisit it, but for now it's probably good enough workaround.

[radeusgd]

Other alternative is - shall we cease testing the private HTTP.fetch method and instead rely on Data.fetch?

HTTP.fetch is the low-level one that relies on the consumer ensuring that the stream is processed, and avoids any auto-materialization for efficiency.

Data.fetch is the user-facing one that already handles the materialization - so even if the result is not consumed, the stream will have already been closed. That was the rationale of stream materialization - wrap streams passed to the user ensuring that they can be used 0 or multiple times VS exactly-once semantics of HTTP.fetch.

[GregoryTravis]

Yes, I think this is a good idea -- I've added it to #11879, which will be done sooner than a full solution to the problem.

[radeusgd]

Workaround looks good.

I'm wondering if Data.fetch could also work as an alternative. But I think it's good enough as-is
and this is just to stabilize the tests, we need to look into the root cause anyway.