Limit metric tag to concrete message type

[lailabougria]

related to #7022

Currently, a metric tag containing the content of the EnclosedMessageTypes header is added to the Fetches, Failures, and Success metrics emitted through System.Diagnostics in Core.

However, the value of this header can be quite large, and doesn't provide as much value, as filtering makes most sense on the message type, not its entire hierarchy tree.
This PR changes that value to be limited to the most concrete message type, and only includes the message type full name, and excludes assembly info.

The full contents of the header are still emitted as trace tags.

[SzymonPobiega]

Nitpicking ;)

[bbrandt]

Would we ever want to handle a weirdly formatted message type string that starts with a ;. Maybe this is too edge and we'd want to fix the thing creating the buggy data instead.

using System;
using System.Linq;

namespace HelloWorld
{
	public class Program
	{
		public static void Main(string[] args)
		{
		  var messageTypes = ";ClassName1,unecessary information;ClassName2,unecessary information";
			var messageTypeHeader = !string.IsNullOrEmpty(messageTypes) ? messageTypes.Split(';').FirstOrDefault(s => !string.IsNullOrEmpty(s)) : null;
			var messageTypeName = !string.IsNullOrEmpty(messageTypeHeader) ? messageTypeHeader.Split(',').FirstOrDefault(s => !string.IsNullOrEmpty(s)) : null;
			
			Console.WriteLine(messageTypeName);
		}
	}
}

[bbrandt]

@lailabougria Usually, we like to cache these types of string manipulations in a ConcurrentDictionary for performance reasons?

NServiceBus/src/NServiceBus.Core/Pipeline/Incoming/DeserializeMessageConnector.cs

Line 72 in fd29208

messageTypes = enclosedMessageTypesStringToMessageTypes.GetOrAdd(enclosedMessageTypesValue,

https://github.com/Eventellect/SupportRepro/blob/39b6264282688f21737990014e2b5b72faa4b660/src/NSB.Extensions/EnclosedMessageTypesMappingBehavior.cs#L59

[lailabougria]

@bbrandt Thanks for pointing out the caching optimization; we'll look into this and, if needed, raise a follow-up PR.

Regarding your first question, we wouldn't handle that scenario because we assume this input was either:

• created by another nservicebus endpoint
• created by a user in native-integration scenarios, which would never work with that type of input anyway

If it were to happen that the header is formatted as you suggested, then it would not fail in this code, but rather have an empty value inside the metric tag. However, it would later fail in deserializing the message, and cause message processing to fail (which you would see reflected in traces).