fix: Add metrics for reliably measuring Block Stream/Executor health

[morgsmccauley]

The current methods for determining both Block Stream and Executor health is flawed. This PR addresses these flaws by adding new, more reliable, metrics for use within Grafana.

Block Streams

A Block Stream is considered healthy if LAST_PROCESSED_BLOCK is continuously incremented, i.e. we are continuously downloading blocks from S3. This is flawed for the following reasons:

1. When the Redis Stream if full, we halt the Block Stream, preventing it from processing more blocks
2. When a Block Stream is intentionally stopped, we no longer process blocks

To address these flaws, I've introduced a new dedicated metric: BLOCK_STREAM_UP, which:

• is incremented every time the Block Stream future is polled, i.e. the task is doing work. A static value means unhealthy.
• is removed when the Block Stream is stopped, so that it doesn't trigger the false positive described above

Executors

An Executor is considered unhealthy if: it has messages in the Redis Stream, and no reported execution durations. The latter only being recorded on success. The inverse of this is used to determine "healthy". This is flawed for the following reasons:

1. We distinguish the difference between a genuinely broken Indexer, and one broken due to system failures
2. "health" is only determined when there are messages in Redis, meaning we catch the issue later than possible

To address these I have added the following metrics:

1. EXECUTOR_UP which is incremented on every Executor loop, like above, a static value means unhealthy.
2. SUCCESSFUL_EXECUTIONS/FAILED_EXECUTIONS which track successful/failed executions directly, rather than tracking using durations. This will be useful for tracking health of specific Indexers, e.g. the staking indexer should never have failed executions.