use new miner_telemetry hashrate values and update openAPI schema

[GitGab19]

This PR updates the openAPI schema to the latest changes introduced by stratum-mining/sv2-apps#553.

It also makes dashboard use miner_telemetry hashrate values (measured from underlying apps through asic-rs) instead of the vardiff estimated ones.

Closes #188

[GitGab19]

@lucasbalieiro this PR is still draft because while testing it with my Bitaxe I noticed that the miner_telemetry values where not retrieved from both JDC and tProxy (expect for the make and model fields).

I won't have access to my Bitaxe for the next days, so I would appreciate your help on figuring out what's going on here.

I still don't know if the issue is in our apps, in the docker images, or related to docker networking stuff.

What I know is that if you run apps on our current main, it works like a charm, and all the values are correctly retrieved, so it seems there's a difference between the apps and the docker images..

[lucasbalieiro]

Ok, gonna check today.

[lucasbalieiro]

just posting a summary of what we've been discussing:

when tProxy/JDC runs inside a Docker container using the default bridge network, the peer IPs it observes are NATed by Docker. As a result, multiple ASICs appear to originate from the same bridge gateway IP instead of their actual LAN IP. The screenshot below confirms this behavior.

This is expected for bridge networking. See Docker's networking documentation: https://docs.docker.com/engine/network/port-publishing/.

The issue is that we need the miner's real LAN IP to make the HTTP request that fetches its telemetry.

This is probably not an issue for Umbrel, since we use network_mode: host, which avoids the bridge NAT. However, we also need to support Windows and macOS, where host networking is not a portable option.

I can think of a few approaches:

• Keep using host networking where available and accept a different implementation on Windows/macOS.
• Investigate Linux specific networking options such as direct routing, macvlan, or ipvlan, although these are not portable to Docker Desktop and would increase deployment complexity.
• Perform a LAN scan to discover miners, fetch telemetry from each discovered IP, and then correlate the results using user_identity.

At the moment, the LAN scan seems like the most portable solution. The downside is that it duplicates logic that we intended to centralize in the sv2 apps, since sv2-ui would have to rediscover miners instead of relying on tProxy/JDC. (and sv2-ui is also running inside docker)

[GitGab19]

@lucasbalieiro what happens if you enable host networking in your Docker Desktop?

Does the container see the real miner IP?

[lucasbalieiro]

currently exploring a new way.
using Docker Desktop version 4.34 and later

enabling Host Network manually. This comes disabled by default: