Add a new remote I/O backend based on libcurl poll-based multi API

[kingcrimsontianyu]

This PR adds a new backend for KvikIO remote I/O client using libcurl's poll-based multi interface. Three new settings are introduced, configurable both via environment variables or programmatically:

• KVIKIO_REMOTE_BACKEND: LIBCURL_EASY (default, using the existing easy handle backend), LIBCURL_MULTI_POLL (using the new backend created in this PR).
• KVIKIO_REMOTE_MAX_CONNECTIONS: The number of easy handles attached to a multi handle (defaults to 8).
• KVIKIO_NUM_BOUNCE_BUFFERS: The k value in k-way bounce buffer.

The current implementation has the following details, subject to future changes:

• When the poll-based backend is used, a pread call splits the I/O into chunks of fixed size, just like the easy handle backend. But the chunked reads are not processed in parallel in the thread pool, they are instead processed on a single thread from the thread pool in a multiplexed fashion, enabled by libcurl's multi interface.
• For the same remote handle, different pread calls are executed in sequence, enforced by a mutex.
• For different remote handles, different pread can be executed in parallel in the thread pool.

This PR depends on #898, which makes the bounce buffer moveable.

Addresses most of #786

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[madsbk]

@kingcrimsontianyu did you see any performance improvements with this new backend?

[madsbk]

Would it make sense to use this everywhere we need a bounce buffer? If so, I think it would be good to move BounceBufferManager out of this PR and submit a separate PR that introduces BounceBufferManager and uses it consistently across the KvikIO?

[kingcrimsontianyu]

Yes. I agree. This will generalize #520 (double buffering), and benefit existing local and remote I/O handles based on pread/io_uring/easy handle.

[kingcrimsontianyu]

@madsbk So far I've only performed correctness tests, and will work on the performance tests next.

[kingcrimsontianyu]

This PR will slip 26.02. I will work on the bounce buffer PR first, then pick up this one.
So far this PR is a tentative application of multiplexing on a single file range (split into chunks), of a single file handle. We will need to extend it to vector of file ranges of a single file handle, and more generally, vector of file ranges from multiple file handles (#899). Whether doing these in one sitting of PR or spanning multiple ones, I will defer the decision until a later time.
cc @madsbk @vuule

[madsbk]

If it doesn't require too many casts, it would be good to use std::byte* instead void* throughout.

Suggested change

	void* data() const noexcept;
	std::byte* data() const noexcept;

[kingcrimsontianyu]

Agreed.
Currently we have quite a number of places where void* has been used for buffers from function parameters and class data members. There are other places where char* is used to facilitate interaction with libcurl API. Perhaps for the public interface we still use void*, but internally wherever applicable, we stick to std::byte*. Let's defer this to a future, modernization PR.

[madsbk]

What happens if the user uses set_task_size() or set_bounce_buffer_size() after RemoteHandlePollBased has been construed? Do we need checks later as well?