Simplify SNI tracing

[Wraith2]

In some methods the code overhead of event tracing becomes higher than the code itself. For example:

        public override uint SendAsync(SNIPacket packet, SNIAsyncCallback callback = null)
        {
            long scopeID = SqlClientEventSource.Log.TrySNIScopeEnterEvent(s_className);
            try
            {
                SNIAsyncCallback cb = callback ?? _sendCallback;
                packet.WriteToStreamAsync(_stream, cb, SNIProviders.TCP_PROV);
                SqlClientEventSource.Log.TrySNITraceEvent(s_className, EventType.INFO, "Connection Id {0}, Data sent to stream asynchronously", args0: _connectionId);
                return TdsEnums.SNI_SUCCESS_IO_PENDING;
            }
            finally
            {
                SqlClientEventSource.Log.TrySNIScopeLeaveEvent(scopeID);
            }
        }

Using the TrySNIEventScope struct introduced in the Mars muxer rework this can be simplified to:

        public override uint SendAsync(SNIPacket packet, SNIAsyncCallback callback = null)
        {
            using (TrySNIEventScope.Create(nameof(SNITCPHandle)))
            {
                SNIAsyncCallback cb = callback ?? _sendCallback;
                packet.WriteToStreamAsync(_stream, cb, SNIProviders.TCP_PROV);
                SqlClientEventSource.Log.TrySNITraceEvent(nameof(SNITCPHandle), EventType.INFO, "Connection Id {0}, Data sent to stream asynchronously", args0: _connectionId);
                return TdsEnums.SNI_SUCCESS_IO_PENDING;
            }
        }

which is visually cleaner allowing you to focus on the important code not tracing.

I have also removed use of constant s_className variables because using the nameof() expression allows the compiler to embed and intern the required string making codegen cleaner. Instead of loading a variable each time the literal string location in memory can be hardcoded by the jit reducing the tracing overhead even when it is not used by reducing codesize.

[JRahnama]

LGTM. Nice approach. Have you tested the results from PerfView as well? Can you share the results to see if those are working as expected please?

[Wraith2]

I haven't tested from perfview, I'm not sure how I'd do that, I'm not an experienced user of perfview.
Logically the output should be identical.

[JRahnama]

My only concern was that EventSource is happenign out of the process (this is why it is not good to capture serialized objects) and I was wondering about whent he dispose happens and how/where the log is going to be printed, but according to MS documentation it is fine using that.

Once more Thanks for the support.

[Wraith2]

Usings are lowered by the compiler into try finally blocks. In the case where there are multiple using blocks they're lowered individually so that inner finally blocks happen before outers so we get preserved ordering. We should end up with equivalent code or in the case with multiple usings slightly safer code (because an error in a finally won't prevent another finally).

The intention and expected result is that everything should function exactly as before but be slightly easier to read.

[johnnypham]

Event ordering looked identical in my tests. LGTM!