subscriber: add EnvFilter::builder, option to disable regex

[hawkw]

Motivation

Currently, EnvFilter will always interpret all field value filter
directives that are not numeric,or boolean literals as regular
expressions that are matched against a field's fmt::Debug output. In
many cases, it may not be desirable to use regular expressions in this
case, so users may prefer to perform literal matching of fmt::Debug
output against a string value instead. Currently, this is not possible.

Solution

This branch introduces the ability to control whether an EnvFilter
interprets field value fmt::Debug match filters as regular expressions
or as literal strings. When matching literal fmt::Debug patterns, the
string is matched without requiring a temporary allocation for the
formatted representation by implementing fmt::Write for a matcher type
and "writing" the field's Debug output to it. This is similar to the
technique already used for matching regular expression patterns.

Since there is not currently a nice way to specify configurations prior
to parsing an EnvFilter from a string or environment variable, I've
also added a builder API. This allows setting things like whether field
value filters should use strict matching or regular expressions.

Notes

Ideally, I think we would want the filter language to allow specifying
whether a field value filter should be interpreted as a regular
expression or as a literal string match. Instead of having a global
toggle between regular expressions and literal strings, we would
introduce new syntax for indicating that a value match pattern is a
regular expression. This way, a single filter can have both regular
expression and literal string value matchers. The with_regex(false)
configuration would just return an error any time the regex syntax was
used when parsing the filter string.

However, this would be a breaking change in behavior. Currently, field
value filters are interpreted as regex by default, so changing the
parser to only interpret a value filter as a regex if there's additional
syntax indicating it's a regex would break existing filter
configurations that rely on regex matching.

In tracing-subscriber 0.4, we should definitely consider introducing
new syntax to indicate a match pattern is a regex, and change the
with_regex method's behavior to disallow the use of that syntax. For
now, however, making it a global toggle at least allows users to control
whether or not we use regex matching, so this is a significant
improvement for v0.3.x.

[hawkw]

cc @CAD97

[CAD97]

Currently, EnvFilter will always interpret all field value filter directives that are not [...] string literals as regular expressions

No, string "literals" are also interpreted as regex 😅

Ideally, I think we would want the filter language to allow specifying whether a field value filter should be interpreted as a regular expression or as a literal string match.

FWIW, my nextgen sketches do this. Currently it only supports "whole string" literal matches, not substring (requiring regex for substring matches), but this is easily adjustable.

Otherwise, LGTM

[hawkw]

@CAD97:

No, string "literals" are also interpreted as regex 😅

Ahahaha, whoops, I thought there was a line here that tries to interpret a quoted string as a literal first:

tracing/tracing-subscriber/src/filter/env/field.rs

Lines 210 to 213 in a3e7944

	.or_else(|_| {
	s.parse::<MatchPattern>()
	.map(|p| ValueMatch::Pat(Box::new(p)))
	})

but I guess there isn't! Congratulations, you have the dubious honor of knowing this code better than I do...

FWIW, my nextgen sketches do this. Currently it only supports "whole string" literal matches, not substring (requiring regex for substring matches), but this is easily adjustable.

Yeah, I think this makes sense for now; we should definitely default to matching whole string literals, and make regex support an opt-in feature (if we add it at all).

[hawkw]

@davidbarsky I think I've addressed all your suggestions? LMKWYT!