snet: Path lookup in snet.Write greatly degrades performance when called in parallel

[scrye]

Whenever an application writes via snet.Conn to a remote address with an unset path, snet will try to retrieve the path from SCIOND. This blocks the calling goroutine, but also any other goroutine trying to write, even if they might want to send data via a known path.

This needs to be fixed s.t. snet only blocks the calling goroutine. One possible solution is to move path resolution outside of the global internal lock.

Note that this can be tricky to handle when callers change the write deadline of the socket (via SetWriteDeadline or SetDeadline) to some time in the past, as in this case net.PacketConn dictates that the call should return (see https://golang.org/pkg/net/#PacketConn):

// A deadline is an absolute time after which I/O operations
// fail with a timeout (see type Error) instead of
// blocking. The deadline applies to all future and pending
// I/O, not just the immediately following call to ReadFrom or
// WriteTo. After a deadline has been exceeded, the connection
// can be refreshed by setting a deadline in the future.

In other words, the path request should be canceled when the deadline is exceeded, including the case where the deadline has been changed after the call to get paths. This might mean maintaining a queue of cancelFuncs that tracks active SCIOND queries.

This requires #1701 to be implemented first.