Implement Extensions Negotiation and Worker Specific Hashrate Tracking in applications

[GitGab19]

This PR implements the two extensions on our applications.

It's based on my other work on stratum, which can be found here: stratum-mining/stratum#1983.

Still WIP:

• Pool
• tProxy
• JDC
• integration tests with extensions enabled

[GitGab19]

I still need to consider if it's worth adding some new integration tests, but the PR is definitely ready for review.

It's entirely based on my other work in stratum-mining/stratum#1983, so you should take a look at both PRs if you want to review it.

[bit-aloo]

@GitGab19 Currently, our approach for handling roles is to convert the frame into a message as soon as it’s received. We avoid passing or circulating raw frames internally since we’ve previously observed occasional message corruptions with that approach. I’ll review this PR soon that should give me a clearer picture to discuss the frame orchestration in more detail. I am still reviewing the core extension stuff.

[xyephy]

@GitGab19 Nice work on the extensions implementation! Everything compiles, tests pass, and all of Shourya's feedback is addressed.

Edge Case Found (not blocking, pre-existing from main):
Line 423 in channel_manager.rs can panic if downstream sends binary (non-UTF8) user_identity:

• Binary input (255 bytes) → hex encoding (0x + 510 chars = 512 bytes)
• Append .translator-proxy (+18 bytes) = 530 bytes total
• .try_into::<Str0255>().unwrap() panics because 530 > 255 max

This is unrelated to your extensions work - just something I noticed during review. Happy to open a follow-up PR if you think it's worth fixing, otherwise we can leave it. What do you think?

[GitGab19]

Line 423 in channel_manager.rs can panic if downstream sends binary (non-UTF8) user_identity

The user_identity used there comes from the internal OpenExtendedMiningChannel message which is crafted by the Sv1Server, which takes the user_identity value from the tProxy config file. Probably we should also add some checks there (?)

Happy to open a follow-up PR if you think it's worth fixing, otherwise we can leave it.

Let's log this as an issue, and let's tackle it in a follow-up PR.

[bit-aloo]

ACK