tcp: unexport TcpTransport.Upgrader

[marten-seemann]

All that users care about is that the transport constructed is a tpt.Transport, they don't care about the (incorrectly capitalised) TcpTransport.

This PR doesn't solve any particular issue, but it's part of a cleanup of our exposed API. As a reference point, the QUIC transport doesn't expose any transport either.

[Stebalien]

This was intentional. The convention is to have constructors return a concrete, public type. That lets us add additional methods, expose the upgrader, etc. in case the user wants to change TCP specific options.

That's less of an issue now that the transport takes functional options, but it's still convenient to be able to expose custom methods/metadata on transports.

[marten-seemann]

Fair enough. I don't think we're using it, but it might be useful at some point.

I disagree regarding the upgrader though. Modifying that member variable will always be racy, so the only thing you can safely do is a read access. If we ever need to give access to that, a getter function would be the better API.

[Stebalien]

I disagree regarding the upgrader though. Modifying that member variable will always be racy, so the only thing you can safely do is a read access. If we ever need to give access to that, a getter function would be the better API.

Yeah, you're probably right. IIRC we did that due to a limitation in our libp2p constructor (which is no longer an issue).

[MarcoPolo]

If we don't need to expose this and we can minimize the api surface then it seems like a win :)

[marten-seemann]

I removed the last commit, so this is now just making TcpTransport.Upgrader private.