core: Rework ValueSets to support indexing in addition to visiting

[davidbarsky]

Feature Request

Crates

• tracing-core

Motivation

The current tracing_core::field::ValueSet requires users to implement a visitor to process and record Values. While this is performant, users have expressed confusion and occasional frustration with this requirement.

Proposal

We should consider dispatching Value primitive values using an enum rather than a trait object in order to... (I'm not sure, @hawkw, can you add additional details?)

[hawkw]

@hawkw shared a sketch of a possible approach.

This is a sketch of the enum-based Value dispatch (#925), not of an indexable ValueSet.

[davidbarsky]

Whoops, fixed. Sorry about that!

[hawkw]

Okay, I talked it over with @carllerche a bit, and I think that the proposal for this is basically:

• change ValueSet to be represented by &'a [Option<&'a dyn Value>] rather than &'a [(Field, Option<&'a dyn Value>)]
• change the tracing-core ValueSet constructor to just require that the slice that's passed in is in order (and have the macros ensure that it is); document this on the off chance anyone else ever consumes this low-level API.
• Higher level APIs can have some kind of builder for valuesets, or we can just deprecate/remove the record_all batched recording APIs. We could change the Subscriber::record method to just take a single field and Value --- AFAICT, nobody ever uses anything else.
• Allow indexing ValueSets with Fields.

(note that Value will probably also stop being a trait object, but I didn't reflect that above because that's a separate issue, #925)