metrics: transition all metrics to using metricsgen generated constructors.

[williambanfield]

What does this change do?

This pull request completes the change to the metricsgen metrics. It adds go generate directives to all of the files containing the Metrics structs.

Using the outputs of metricsdiff between these generated metrics and master, we can see that there is not a diff between the two sets of metrics when run locally.

[william@sidewinder] tendermint[wb/metrics-gen-transition]:. ◆ ./scripts/metricsgen/metricsdiff/metricsdiff metrics_master metrics_generated
[william@sidewinder] tendermint[wb/metrics-gen-transition]:. ◆

This change also adds parsing for a metrics: key in a field comment. If a comment line begins with //metrics: the rest of the line is interpreted to be the metric help text. Additionally, a bug where lists of labels were not properly quoted in the metricsgen rendered output was fixed.

[creachadair]

The metricsgen tool grabs the comments above each metric field and uses this as the help text for the metric. This help text is accurate but may be a bit verbose. It's also incorrectly formatted in some cases, where the Go comments contain UpperCamel whereas the metric name is in lower_snake. Should we consider adding an additional field or comment tag to include an additional 'shortened' commented that's just for the metricsgen output?

I think a useful metric description might be too long for a field tag—not an implementation limit, but just in terms of practical legibility.

One thing we could do is to add markers into the comment, and document it as such. E.g., something like "If the comment attached to the field has a line beginning with "metric:text", the rest of that line is used as the description text for the metric; otherwise the first line of the comment itself is used."

Or something along those lines. That would allow reasonably normal comment usage (and a magic tag is pretty easy for the reader to see and avoid clobbering).

I think it's fine to have some documented rules about how to inform the code generator, as long as they don't interfere too much with normal usage.

Another option would be to do surgery on the standard comment format, e.g., grab the text and strip off the head of "(An? )?(MetricName( is)?) blah blah blah" and capitalize what's left. Bu that seems a little too subtle.

[williambanfield]

One thing we could do is to add markers into the comment, and document it as such. E.g., something like "If the comment attached to the field has a line beginning with "metric:text", the rest of that line is used as the description text for the metric; otherwise the first line of the comment itself is used."

I've implemented this solution. I think it's simple enough and not particularly intrusive. It generates nice output and keeps all of the metric information in one place.