feat(network): Add ConnAs

[MarcoPolo]

ConnAs works in a similar way to errors.As. It allows a user to cut through the interface layers and extract a specific type of connection if available.

This serves as a sort of escape hatch to allow users to leverage some connection specific feature without having to support that feature for all connections. Getting RTT information is one example.

It also allows us, within the library, to get specific types of connections out of the interface box. This would have been useful in the recent changes in tcpreuse. See #3181 and #3142.

Getting access to the underlying type can lead to hard to debug issues. For example, if a user mutates connection state on the underlying type, hooks that relied on only mutating that state from the wrapped connection would never be called.

It is up to the user to ensure they are using this safely.

[sukunrt]

How about adding Unwrap too?
#3196

Though that proposal forces to unwrap to a manet.Conn always.

[sukunrt]

Alternatively, for your use case I think the better approach is to add RTT() network.Duration to the Conn and setting the value really high or negative for transports that don't support this.

Providing RTT seems useful.

[marten-seemann]

Alternatively, for your use case I think the better approach is to add RTT() network.Duration to the Conn and setting the value really high or negative for transports that don't support this.

Providing RTT seems useful.

You probably also want RTT variance, min RTT, etc.

[MarcoPolo]

I think the better approach is to add RTT() network.Duration to the Conn

This is certainly something we can do. It's better in the sense that it doesn't expose the knives to users. But on the other hand sometimes you want the knives.

We could easily add the RTT() method to conn and implement it with ConnAs, so I think we probably still want ConnAs.

[sukunrt]

The underlying transport method exposing the RTT might have any signature, like exposing the RTT, RTT variance, minRTT from a single method. Why would you want to implement the RTT method with ConnAs as opposed to exposing a RTT method from transport.CapableConn which wraps whatever that specific transport does?

[MarcoPolo]

... as opposed to exposing a RTT method from transport.CapableConn which wraps whatever that specific transport does?

Maybe there's a misunderstanding? I'm saying that even with this method you would still want ConnAs so that you can cut through the layers of abstraction and match against a specific transport.