Adopt quicksink

[kayabaNerve]

Description

libp2p should inline quicksink into the rust-libp2p monorepo. libp2p is a notable consumer of quicksink with overlapping developers from the current organization responsible for it.

Motivation

Despite libp2p's active usage of quicksink, it hasn't been maintained since 2022 and has dated dependencies. While I would simply make a PR to quicksink to bump said dependencies, I can't as the repository is archived.

I did attempt to remove the reliance on quicksink as discussed a year and a half ago in #2653 (comment). Unfortunately, offering the Sink API around something without the Sink API requires effectively the entire quicksink library of code. Accordingly, there's no benefit to removing it vs adopting it.

The alternative would be to use future's unfold, dropping the ability to flush and deferring the close operation to Drop. While I can't claim experience with this level, that seemed unwise.

Requirements

Potentially the consent of the prior organization to accept the quicksink crate unless libp2p wants to inline it as a file within libp2p-websocket (the one consumer)/rename it to quicksink2.

Open questions

No response

Are you planning to do it yourself in a pull request ?

Maybe

[thomaseizinger]

libp2p should inline quicksink into the rust-libp2p monorepo.

Is it used in several places? I am happy to have the code inlined into the usage site. It would be great if we don't have to add a crate to our workspace.

[kayabaNerve]

It's a single use to add Sink to soketto::Connection (meaning an alternative may be adding Sink directly to soketto::Connection?).

I'd guess the easiest option will be to the single-file crate into a single-file module, as inlining it seems to be redoing all of it. If you can write a tailored solution due to better understanding the problem space, I'd love to see it :)

[thomaseizinger]

Inline the crate into a module is fine, then we have control over the dependencies :)