EDIT: we'll proceed with Option 1.

For the same project as discussed in #30984, I'm using nettest.TestConn to test a custom net.Conn implementation.

Now that I've got the basics covered, I realize it'd be useful to be able to extend the tests to make sure that my CloseRead/CloseWrite methods that are not a mandatory part of net.Conn could also be tested on my type.

I see two options here:

1. Allow TestConn to perform a couple of type assertion tests to see if methods such as CloseRead and CloseWrite are implemented on the net.Conn type, and then run additional tests if so.

This has the advantage that anyone who consumes this package and passes a net.Conn with these methods will have these tests run. net.TCPConn, net.UnixConn, and my custom vsock.Conn type (as an example) would run these added tests, but net.UDPConn would not.

Perhaps it'd also make a sense to have an optional test for SyscallConn as well, since it is widely implemented.

2. Export timeoutWrapper and connTester in some form, to enable callers to create their own local tests in a nettest.TestConn-style.

This could be nice to keep the amount of code in this package smaller, but it'd also mean that certain tests such as the CloseRead/CloseWrite would need to be duplicated between different projects.

With this said, I think option 1 is preferable in order to reduce duplication in the community, but I can understand why one wouldn't want to add additional complexity to this package to test methods that are not a required part of net.Conn.

/cc @dsnet @mikioh @acln0