misc: make RwStreamSink an implementation detail of the memory transport

[thomaseizinger]

The crate rw-stream-sink is a top-level crate in our misc/ directory but it is only in use in two places:

• For the implementation of the memory transport
• Within a test in multistream-select

To lower the maintenance effort of the repository, I'd like this crate to be inlined into the memory-transport implementation, ideally as an implementation detail (i.e. not part of the public API).

rw-stream-sink is still published on crates.io, so my suggestion would be to simply depend on it via that for the multistream-select test. This allows us to delete the crate from our repository and move the code into the memory-transport implementation.

[thomaseizinger]

@mxinden Let me know if you agree.

[mxinden]

I don't have a strong opinion on this. That said, I don't recall this crate causing any significant work. I suggest not investing the time to remove it until such significant work would otherwise be required.

[thomaseizinger]

That said, I don't recall this crate causing any significant work. I suggest not investing the time to remove it until such significant work would otherwise be required.

It is true that there is not active workload on the crate. It does cause passive, cognitive complexity because it shows up in the project explorer and in our list of CI jobs.

Thus, I think it is a net positive work item and a great candidate for an external contribution.

[mxinden]

Thus, I think it is a net positive work item and a great candidate for an external contribution.

👍 in favor of removing decision-pending

[elenaf9]

As far as I can tell rw-stream-sink is also used in the websocket transport, and with #4120 in the libp2p crate as well.

So IMO we should keep it as a crate in misc/. Let me know if I a missing something :)