This saves us a non-inlineable function call. Thread local block is
accessed anyway, since we need to get the token, so we already have the
pointer and don't need to get it a second time (which is done inside
Windows' GetCurrentThreadId()). We also don't need to store the thread
id in ScopedZone anymore, as it was a micro-optimization to save us the
second GetThreadHandle() call.
This change has a measurable effect of reducing enqueue time from ~10 to
~8 ns.
A further optimization would be to completely skip thread handle
retrieval during zone capture and do it instead on retrieval of data
from the queue. Since each thread has its own producer ("token"), the
thread handle should be accessible during the dequeue operation. This is
a much more invasive change, that would require a) modification of the
queue, b) additional processing of dequeued data to inject the thread
handle.
Long-lived zones could send their end events without begin events in a
following scenario:
1. On-demand connection is made.
2. Zone begin is emitted, m_active is set to true.
3. Connection is terminated.
4. A new connection is made.
5. Zone end is emitted, because m_active is true.
To this point it was assumed that all zone end events will happen before
a new connection is made, but it's not necessarily true.
There are only two cases for which HandleServerQuery() returns false.
Either data can't be read from the socket (which is checked by HasData()
call before calling HandleServerQuery()), or if the server sent
termination query. In both these cases there's no need to send data
anymore.
