Allocation requests stuck after being canceled.

[davidzhao]

When ICE clients test connectivity via different candidates, it'll start an allocation request with TURN. However, when it ultimately chose a better path, the TURN stack would be stuck reading for a long time. After running the server in production, it's typical to be left with the following goroutines, even if there are no clients that are using TURN.

We need a timeout in Allocation.packetHandler to allow it to cleanup sooner.

goroutine 11369246 [IO wait]:
internal/poll.runtime_pollWait(0x7fc925567e98, 0x72)
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/runtime/netpoll.go:234 +0x89
internal/poll.(*pollDesc).wait(0xc00b7d3800, 0xc001400300, 0x0)
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/internal/poll/fd_poll_runtime.go:84 +0x32
internal/poll.(*pollDesc).waitRead(...)
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).ReadFrom(0xc00b7d3800, {0xc001400300, 0x640, 0x640})
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/internal/poll/fd_unix.go:223 +0x238
net.(*netFD).readFrom(0xc00b7d3800, {0xc001400300, 0x0, 0x4c77c6})
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/net/fd_posix.go:62 +0x29
net.(*UDPConn).readFrom(0x17cab60, {0xc001400300, 0x0, 0x5afea8}, 0xc0014fa2d0)
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/net/udpsock_posix.go:47 +0x3e
net.(*UDPConn).readFromUDP(0xc0465e46a8, {0xc001400300, 0xc0465e46a8, 0x4bb197}, 0xc000febe40)
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/net/udpsock.go:116 +0x31
net.(*UDPConn).ReadFrom(0xc0465e46a8, {0xc001400300, 0x640, 0x640})
	/opt/homebrew/Cellar/go/1.17.6/libexec/src/net/udpsock.go:125 +0x50
github.com/pion/turn/v2/internal/allocation.(*Allocation).packetHandler(0xc000114840, 0xc022ce5180)
	/Users/davidzhao/dev/livekit-research/turn/internal/allocation/allocation.go:249 +0xc3
created by github.com/pion/turn/v2/internal/allocation.(*Manager).CreateAllocation
	/Users/davidzhao/dev/livekit-research/turn/internal/allocation/allocation_manager.go:120 +0x4bd