metrics: Introduce MetricBuilderRegistry for instrumenting expression…

…s in server stack

Problem

Metrics creations are scattered in many stack modules, each stack module has its
filter and independent from others. However, instrumenting an expression needs
access to all component metrics.

Solution

Introduce a stack param to cache metrics as well as providing lazy vals to create
expressions.

Result

The original approach was having a stack.module that sits at the end of the
stack where all needed metrics are generated. the downside is it registers the
same expressions many times (= connections), and the last override the previous
ones.  The current approach should reduce the expression evaluation time, but
requires implementors to have more context on the finagle stack for metrics
creation sequence.

Differential Revision: https://phabricator.twitter.biz/D663915

server/src/main/scala/com/twitter/server/handler/MetricExpressionHandler.scala

@@ -24,7 +24,7 @@ import com.twitter.server.util.{AdminJsonConverter, MetricSchemaSource}
 import com.twitter.util.Future
 
 object MetricExpressionHandler {
-  private val Version = 0.7
+  private val Version = 1.0
   private val statsFormatter = StatsFormatter.default
 
   /**

server/src/test/scala/com/twitter/server/handler/exp/MetricExpressionHandlerTest.scala

@@ -95,7 +95,7 @@ class MetricExpressionHandlerTest extends AnyFunSuite {
     val expectedResponse =
       """
         |{
-        |  "@version" : 0.7,
+        |  "@version" : 1.0,
         |  "counters_latched" : false,
         |  "separator_char" : "/",
         |  "expressions" : [