crypto/tls: Clean up semantics of copying/immutability of tls.Config in 1.8.

[agl]

A function to copy a tls.Config should probably be exposed in 1.8 because net/http could use it. Also, the current DialWithDialer function copies the config in order to set an SNI value, but that has a complex interaction if the Config is being used for serving. Maybe that's an unreasonable use-case but, if so, what's reasonable could be better documented.

[jboelter]

also #15771

[josharian]

also #16228

[gopherbot]

CL https://golang.org/cl/28075 mentions this issue.

[bradfitz]

Also, the current DialWithDialer function copies the config in order to set an SNI value, but that has a complex interaction if the Config is being used for serving.

The net/http package also has its own variant of tls.Config.Clone which configs most but not all fields for the same or similar field race reason, because you can't clone a Config already in use for serving.

tls.Config.CloneClient? Kinda gross.

[lmb]

Maybe the right step is to make the exported Clone() skip the SessionTickets* variable? This would break session resumption on cloned Config, but that seems like less of a foot gun than having to discern what kind of copy we want.

Also, I think the title of this issue should be amended to mention that DialWithDialer is currently racy.

[bradfitz]

I think https://golang.org/cl/31595 (which didn't mention this issue) was the fix and the last piece of this bug. Closing.