UDP: Fix removeRay will close a connEntry that not belongs to it

[Fangliding]

find in #4897
这样几行就可以 了

[patterniha]

but this is vulnerable to race conditions:

suppose two goroutine run conn.cancel() concurrent, (for example one from timer and one from line-112), name them goroutine-A and goroutine-B.

also suppose we have another concurrent goroutine that run v.Dispatch(), name it goroutine-C.

suppose goroutine-A and goroutine-B pass if entry == v.conn code, but currently only goroutine-A run v.RemoveRay(). (now v.conn is nil)

now suppose goroutine-C run v.getInboundRay before goroutine-B run v.RemoveRay().

so after running v.getInboundRay, v.conn is a new-connection, but now goroutine-B run v.RemoveRay() and it wrongly close the new-connection!!!

///

I know that the probability of this happening is almost zero, but logically is not zero and it should be taken into account.

/////////////////////////////////////////////////////////////////////

also, the v.RemoveRay, should be run, after we're done with dispatcher(defer RemoveRay in socks/shadowsocks/trojan server code)

I can give a rare example where not doing this would cause problems.

and also we should cancel ctx, after udpConn is closed in worker.go.

[Fangliding]

第一个可以弄
第二个udpconn不可用之后它会自己退出的 要不顶多60秒回收
第三个我也没见tcpconn关了之后强绑定ctx取消 自己管自己的就是了

[patterniha]

The second one will exit automatically after udpconn is unavailable, or it will be recycled in 60 seconds at most.

defer udpServer.RemoveRay() cause the outbound-connection close immediately after udpconn is unavailable.

Although it is a rare situation where udpconn is unavailable but outbound-connection is active.

The third one I have never seen before

Canceling ctx cause outbound-pending-Dial close immediately after udpconn is unavailable.

Although it is a rare situation where udpconn is unavailable but outbound-Dial is still pending.

also, if we are in sniffing-state, cause pending-sniffing is closed, and Dial not executed at all.

/////////////

as a result, both are for rare situations, but they are possible anyway and should be fixed.