Support mutating tags on write requests based on headers

[schallert]

Background

We currently have support for restricting query results based on the header M3-Restrict-By-Tags-JSON. This enables
users who have pre-partitioned their metrics before writing them to partition their reads without modifying every
incoming query. The supported operators are EQUAL, NOTEQUAL, REGEXP, NOTREGEXP, EXISTS, and NOTEXISTS.

Similar behavior would be useful on the write path.

Proposal

The proposed fix for this is to add a new header, M3-Map-Tags-By-JSON.

It would have a similar structure to the query Restrict tags but support the following operators: APPEND, DROP, and
REPLACE. More operators could be added over time.

The format of a parsed map header would be:

type MapTagsOptions struct {
	TagMappers []TagMapper `json:"tagMappers"`
}

type TagMapper struct {
	Append  AppendOp  `json:"append"`
	Drop    DropOp    `json:"drop"`
	Replace ReplaceOp `json:"replace"`
}

type AppendOp struct {
	Tag   string `json:"tag"`
	Value string `json:"value"`
}

type DropOp struct {
	Tag   string `json:"tag"`
	Value string `json:"value"`
}

type ReplaceOp struct {
	Tag      string `json:"tag"`
	OldValue string `json:"old"`
	NewValue string `json:"new"`
}

APPEND

APPEND with value tag="foo" and value="bar" would unconditionally add tag-value pair "foo":"bar" to all
timeseries included in the write request. Any timeseries with a non-empty "foo" tag would have its value for that tag
replaced.

DROP

DROP with tag="foo" and an empty value would remove all tag-value pairs in all timeseries in the write request where
the tag was "foo". If value is non-empty, a tag-value pair would only be removed if the value was equal to value.

REPLACE

REPLACE with tag="foo", an empty old field, and a non-empty new field would unconditionally replace the value of
any tag-value pair of any timeseries in the write request where the tag is "foo" with the value of new. If old is
non-empty, a value would only be replaced if the value was equal to old.

Future Operators

The plan is to implement APPEND first and validate it works correctly.

More operators could be added over time, such as operators similar to existing ones but that perform matching or
replaces based on regexes.

Updates:

• Mutate -> Map
• MapTagOptions is an array of mappers each containing an op rather than a bunch of op arrays to make order of operations more clear.

[robskillington]

SGTM, my vote would be for M3-Map-Tags-By-JSON as a name for the header since we're mapping a set to new values, mutate works as well but seems long and not as commonly used for this type of dimension mapping