proto: make initial destination cid configurable

[thynson]

This PR implements #1896.

[Ralith]

Looks reasonable, thanks!

[Ralith]

On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.

[thynson]

On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.

I tried but was stuck with the mutability of the ClientConfig. Maybe some interior mutability pattern should applied here. A mutex is required to do so.

I'll find some time to implement a ClientConfig version in a couple of days.

[djc]

On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.

I tried but was stuck with the mutability of the ClientConfig. Maybe some interior mutability pattern should applied here. A mutex is required to do so.

I'll find some time to implement a ClientConfig version in a couple of days.

Not sure what you mean? EndpointConfig ends up in an Arc inside Endpoint::config, too, so how is the mutability of ClientConfig different/an issue?

[thynson]

On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.

I tried but was stuck with the mutability of the ClientConfig. Maybe some interior mutability pattern should applied here. A mutex is required to do so.
I'll find some time to implement a ClientConfig version in a couple of days.

Not sure what you mean? EndpointConfig ends up in an Arc inside Endpoint::config, too, so how is the mutability of ClientConfig different/an issue?

The EndpointConfig holds an Arc of a factory, when building an Endpoint, an instance of Box<dynConnectionIdGenerator> is obtained from the factory, so the mutability issue is not applied there.

[thynson]

Updated to move it to ClientConfig

[thynson]

Added a commit that replaces ConnectionIdGenerator with function trait instead.
It will be squashed if approved.

[Ralith]

In the long run I want to make ConnectionIdGenerator::generate_cid take &self so we can share them more readily and do away with factories, but that'll be a breaking change regardless, so for simplicity in the short term I think I agree that a function trait object makes the most sense.

[djc]

LGTM, thanks!

[Ralith]

Thanks!