trace: never log access log spans to stdout

[hawkw]

Currently, tracing spans are used to record HTTP access log entries. These spans are recorded at the INFO level, in order to allow the use of fast-path filtering for the more verbose DEBUG and TRACE levels when running with the default tracing filter configuration (linkerd=info) --- if no events will ever be enabled at a given level, tracing can skip them more efficiently than when events with some targets are enabled at that level. The access log spans are recorded with a separate _access_log target, so that the default linkerd=info filter does not enable them.

However, when running with a custom filter configuration that enables info for all targets, the access log spans will be enabled even if access logging is disabled. This means that these spans will be recorded when they may not be needed to generate an access log. They also make logs significantly more verbose when DEBUG events are enabled (only debug and higher events will occur in these spans), which can make the logs harder to parse.

This branch changes the per-layer filter used by the stdout logging layer to explicitly disable the _access_log trace target, regardless of the rest of the filter configuration. This way, a custom filter configuration that globally enables the INFO level will not enable the access log spans, and the spans will not be included in stdout logs even if access logging is enabled. Since the layer that actually generates the access log has its own, separate per-layer filter, the access log spans will still be enabled for that layer, if and only if access logging is actually enabled.

A potential longer-term solution is to rewrite the access logging code to not use tracing, as was originally proposed. At the time, we opted to use tracing to generate the access log because it seemed desirable to have a single set of diagnostics that can generate different outputs. However, in practice, it's probably better to keep general-purpose debugging logs and access logging separate, as they are separate concerns. A purpose-built implementation of access logging could avoid issues like this one, and would also probably be more efficient --- it wouldn't need to allocate strings to represent access log spans, and could instead just store structured data that's formatted directly to the output. But, the filtering change solves the immediate problem.