tProxy hashrate metrics remain stale when `enable_vardiff = false` and upstream adjusts difficulty via `SetTarget`

[gimballock]

Related: #242, PR #245

When enable_vardiff = false (the recommended configuration when using a JDC), the tProxy does not update nominal_hashrate in response to upstream SetTarget messages.

As a result, three hashrate metrics remain stuck at their initial values, even after upstream difficulty changes.

PR #245 fixes the case where the tProxy itself generates UpdateChannel (i.e., when enable_vardiff = true).
It does not fix the SetTarget path, which is the only path used when vardiff is disabled.

Affected Metrics

Metric	Why It's Incorrect
sv2_server_hashrate_total	handle_set_target updates target but not nominal_hashrate
sv2_client_hashrate_total	Same channel, same issue
sv1_hashrate_total	d.hashrate never updated when forwarding difficulty to SV1 miners

All three metrics remain at the value declared in OpenExtendedMiningChannel (derived from min_individual_miner_hashrate), regardless of subsequent upstream difficulty adjustments.

Reproduction

1. Configure tProxy with enable_vardiff = false (typical when using JDC):

   [downstream_difficulty_config]
   min_individual_miner_hashrate = 10_000_000_000_000.0
   shares_per_minute = 6.0
   enable_vardiff = false
   

2. Connect a miner whose actual hashrate differs from the configured value.

3. Allow upstream (JDC or pool) to adjust difficulty via SetTarget.

4. Observe:

• sv2_server_hashrate_total remains at the initial configured value
• sv1_hashrate_total remains at the initial configured value
• The upstream pool correctly reflects adjusted hashrate.

What PR #245 Fixes

When enable_vardiff = true, and the tProxy emits UpdateChannel, it now updates nominal_hashrate.

What's missing:

1. handle_set_target (SV2 path)
When receiving SetTarget, the handler updates channel target(s) but not nominal_hashrate.

2. SV1 downstream hashrate
When vardiff is disabled, difficulty updates are forwarded to SV1 miners but d.hashrate is never updated.

Test Matrix
We should be sure to verify across all 4 variations of enable_vardiff and aggregate_channels to ensure all supported configurations are correctly accounted for.

[GitGab19]

When vardiff is disabled on tProxy side, there's no real way to measure the clients hashrate as you pointed out.

That's why IMO the best thing is to not have any hashrate values returned by the monitoring APIs in that case. Also because in that scenario (where you don't want vardiff on tProxy), you can get the same data from the JDC.

So I would simply change the trait implementation in tProxy, to consider this possible scenario.

[gimballock]

Ok, now when vardiff is disabled on the tProxy, it won't report hashrate metrics, since it didn't independently measure them. The JDC's metrics endpoint is the right source for that information in this topology.

Separate fix included

The PR also includes a fix for the JDC's sv2_server_hashrate_total metric, which was stuck at its initial value because run_vardiff() and handle_update_channel() didn't update upstream_channel.nominal_hashrate before forwarding UpdateChannel to the pool. This is an independent bug — the JDC does measure hashrate via its own vardiff, it just wasn't recording the result locally.