add some bstream metrics

[fschoell]

This adds metrics for:

• blocks/bytes read by filesource from s3
• blocks/bytes sent from filesource
• blocks/bytes sent from livesource
• blocks_behind_live on joiningsource labeled with trace_id

note this depends on streamingfast/dmetrics#1 and streamingfast/dtracing#1 so I can remove the mod replacement

[sduchesneau]

The per-trace_id label is not good in practice, it will increase the size of the prometheus database ridiculously!

from: https://prometheus.io/docs/practices/naming/#labels
CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

This should be either:

1. turned on with a specific debug flag (in which case I don't see how useful it is...)
2. using an "reused" ordinal number instead of the trace_id (in which case it is not that useful...)
   or
3. left out of prometheus and exposed to the investigating sysadmin through other means, ex: logs, custom out-of-band http request, ...

[sduchesneau]

Another way to get information about the state of the firehose (without per-traceid-status) is to use a counter for how many concurrent streams are behind the HEAD.

A simple prometheus gauge could be set to +1 when a joining source reads from the files, and -1 when it becomes live (or when it is shut down, wrapped in a sync.Once.Do()

This means removing the ctx that was added to the joining source and only playing with those counters.