fix: validate username and truncate worker name at authorize time

[average-gary]

The UserIdentity TLV field has a protocol-specified maximum of 32 bytes. When downstream miners send mining.authorize with long worker names, the translator would panic on unwrap().

This fix:

• Rejects mining.authorize if the username portion (before the dot) exceeds 32 bytes, as this indicates an invalid configuration
• Truncates only the worker name portion if the total length exceeds 32 bytes, preserving the username
• Adds defensive error handling in sv1_server.rs as a fallback

[average-gary]

Rebased onto #162

Pr ot that branch here:
Shourya742#1

[gimballock]

Is there a more specific error type we should use here?

[average-gary]

The return type is defined upstream in stratum_core::sv2_api

[GitGab19]

I think we have some misconceptions, and that's probably due to how we called and managed some fields in the DownstreamData in the past.

We currently have authorized_worker_name and user_identity there, but we are currently setting both values with the same string we receive from the mining.authorize message.

Here the changes I would apply:

• rename authorized_worker_name into worker_name_from_authorize to better reflect that this field contains the exact string we receive from the Sv1 mining.authorize
• assign to user_identity only the suffix part of what we receive from the Sv1 mining.authorize (e.g. in case of gitgab.worker1 the user_identity will contain only worker1)
  • if there's no . delimiter, assign the same value as authorized_worker_name
• we don't check the length of any of these fields in the authorize step of the initial "Sv1 handshake", because we don't even know if we need to use the extension or not there
• in the Sv1Server, where we create the TLV using the user_identity field of the DownstreamData we handle the result and, if we get an error from the new() (the check on the length is already made there), we return an error and we disconnect the client

Does it make sense to you @average-gary ?