Support alternate delimiter in EventSourceLogger FilterSpecs

[analogrelay]

Right now, the delimiter that separates individual filter specs in the EventSource logger provider is ;. So multiple filter specs are provided as: Microsoft:Information;System:Information;MyApp:Trace

However, when this is encoded into an .eventpipeconfig file, it ends up looking like this:

Providers=Microsoft-Extensions-Logging:0x4:0:FilterSpecs=Microsoft:Information;SampleWebApp:Trace

The problem is that ; is also the delimiter between individual key/value "parameters" in the .eventpipeconfig file, so if an EventPipe Provider had two key/value pairs (A and B) you'd configure them like this:

Providers=MyProvider:0:0:A=1;B=2, ... other providers ...

Because of this conflict, only the first filter spec actually makes it all the way to EventSourceLogger.

There are a few ways to resolve this:

1. Change coreclr to use a different delimiter other than ; for their parameters, or to support "quoting" or "escaping" of some form (cc @vancem for considering the feasibility of this, given it's already shipped :)).
2. Change EventSourceLogger to support an alternate delimiter (such as |). There are a few ways we could do this:
   a. Use IndexOf to check for one or the other and determine which path to go along
   b. Support using both in a single string
   c. Use a new parameter name (FilterSpecs2) to represent the "new" format.

cc @pakrym @davidfowl

[analogrelay]

@noahfalk @shirhatti for thoughts.

I filed this a while ago in dotnet/extensions (transferring here as part of the migration). Is this relevant to your work on this Logging-EventSource bridge? Basically, the use of a ";" as a delimiter caused some problems with the .eventpipeconfig file format. Now that we're using a named pipe that may not be as relevant.

[noahfalk]

Using ; as a delimeter inside the filter arguments remains awkward because ; delimited provider lists show up in other places too (environment variables, command line parsers for tools). We usually try provide a quoting scheme to make it possible to specify nested semicolons, but it is error-prone for users when different tools use different quoting schemes.

[noahfalk]

In terms of how we solve it, I'd guess ; delimited lists of providers are more commonly known and more widely spread than customers specifying semi-colon delimited lists of logger filter specs. I'd suggest adding support for an alternate filter spec delimeter so nothing that works right now breaks, but it provides a less error-prone syntax to use in the future.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.