feat(miniprotocols): Implement tx submission client

[scarmuega]

No description provided.

[Quantumplation]

Rendered: https://github.com/txpipe/pallas/blob/ee7608a6393cd917a2799d47153d30f3a48049ab/pallas-miniprotocols/src/txsubmission/README.md

[Quantumplation]

Was wondering if I should put some kind of loop here, in case we're waiting for a connection or something, but kept it very minimal;

If there's interest, I could make a recv_init that does the dumb thing, and a wait_for_init that loops until someone connects and sends the init message.

[scarmuega]

well, the recv_message blocks until there's something to read from the channel, the "wait" is imposed to the consumer, even if they don't want it.

Ideally, every blocking call should provide an optional timeout, so that the control flow logic can escape the blocking call if desired. This is an improvement we should make at the multiplexer level, there should be a way to read from a channel with a timeout.

[Quantumplation]

Right but if someone hasn't even connected yet this errors immediately; or is there a construct at the multiplexer / channel level that lets me wait for a connection?

[scarmuega]

I see. I think that our server agent should be created as a result of a successful bearer connection (aka: tcp or unix socket connection).

I imagine the root process waiting for connections on a specific port, this would be a blocking call that is handled by the OS (something like TcpListener::bind("127.0.0.1:3000")). Upon each connection, the process would create a new agent passing a channel connected to our new bearer (inbound socket stream). By this point in time, the calls to recv_message should not fail, but rather block waiting for data.

Summarizing, I think that the initial loop / block is out-of-scope for this crate. I say we create a new example crate (different PR) that shows how to connect our agent to a tcp listener. What do you think?

[Quantumplation]

Makes sense to me; there's nothing in the type system that currently enforces this, though; i.e. I would expect something guiding me to "hey, you opened a connection to the relay, not the other way around, so you can't use this socket/channel to create a server"; see the integration test I added for example.

Is it worth adding a ClientChannel and ServerChannel type to distinguish this?

[Quantumplation]

clippy pls

[scarmuega]

@Quantumplation I think this is ready to merge. We can implement the improvements we discussed as independent PRs. Can you please give it a final review?

[Quantumplation]

@scarmuega LGTM!