feat(metrics): add block transaction count and SR set change monitoring

[warku123]

What does this PR do?

Add two new metrics enhancements for better network monitoring:

1. Block Transaction Count Histogram

   • Replace tron:block_empty_total counter with tron:block_transaction_count histogram
   • Track transaction count distribution per block with buckets: [0, 10, 50, 100, 200, 500, 1000, 2000, 5000, 10000]
   • Empty blocks can be monitored via le=0.0 bucket
   • Remove unused BLOCK_EMPTY counter

2. SR Set Change Monitoring

   • Add tron:sr_set_change counter to track SR membership changes
   • Detect SR additions and removals at each maintenance time interval
   • Labels: action (add/remove), witness (SR address)

Changes:

• Add overloaded init() method in MetricsHistogram for custom buckets
• Add BLOCK_TRANSACTION_COUNT histogram metric
• Add SR_SET_CHANGE counter with SR_ADD/SR_REMOVE labels
• Implement SR set change detection logic in BlockChainMetricManager
• Update PrometheusApiServiceTest with comprehensive test coverage

Why are these changes required?

• Transaction histogram provides richer insights than simple counter for network analysis while maintaining empty block detection capability
• SR set change monitoring enables tracking of network consensus participant changes for governance analysis

Compared to #6602, this PR provides a cleaner implementation focused solely on metrics enhancement without additional complexity.

This PR has been tested by:

• Unit Tests (updated PrometheusApiServiceTest)
• Manual Testing

Follow up

N/A

Extra details

• Closes [Feature] Add Prometheus metrics for empty blocks and SR set changes #6590
• Related to feat(metrics): add block transaction count histogram for empty block monitoring #6602 (alternative cleaner implementation)

[halibobo1205]

The name tron:sr_set_change can be misleading — it sounds like it tracks changes to the entire SR set, when it actually monitors rotation of the top 27 block-producing SRs (Active Witnesses).

Suggested alternatives for better clarity:

• tron:active_sr_change

• tron:active_witness_change

• tron:top27_sr_change

This way, operators can immediately understand what the metric represents when viewing Prometheus dashboards.

[halibobo1205]

The witness label uses addresses. Although the Active SR pool is relatively limited (27 slots), as SRs rotate in and out over time, label values will accumulate monotonically — they only grow, never shrink. This is a known Prometheus anti-pattern.

Practical impact assessment:

• TRON's SR candidate pool is not infinite, and rotation frequency is low, so it won't explode in the short term

• However, as a long-running node metric, months or years of operation could still accumulate a significant number of time series

Possible approaches:

• If the address dimension is truly needed, keep the current design, but document this characteristic

• Or remove the witness label entirely, keeping only action (add/remove), and output address details via logs instead. Follow the principle that Prometheus should be used for alerting and awareness, while logs are for precise investigation and root-cause analysis.