Worker specific hashrate tracking extension (SOLUTION N. 1)

[GitGab19]

After discussing with @TheBlueMatt and @Fi3 about the possible DoS vectors introduced by PR #107 (specifically here), I decided to open a PR to implement SOLUTION N.1 outlined in this doc.

This PR adds an extension to directly send a user_identity field inside a new SubmitIdentifiedSharesExtended. The user_identity field is limited to a maximum of 32 bytes-length to not increase too much the additional bandwidth consumption for extended shares submissions.

[TheBlueMatt]

I left a further comment on the previous thread, but I don't think we need to do this as an extension with new messages, and we need to be careful with extension proliferation or everyone is gonna need to support a billion message types with a million combinations of fields all for the same thing #107 (comment)

[GitGab19]

How would you do it tho? Initially I was thinking about using a new flag in the SetupConnection to tell server that client is going to send user_identity at the end of SubmitSharesExtended message. But this new flag should be handled by existing implementations I guess.

[Fi3]

I left a further comment on the previous thread, but I don't think we need to do this as an extension with new messages, and we need to be careful with extension proliferation or everyone is gonna need to support a billion message types with a million combinations of fields all for the same thing #107 (comment)

do you want to modify the mining protocol? We already released it, braiins already support 2 version demand already support 1 version. While I'm ok in changing other protocols only supported by demand I think that we should stop changing the mining protocol at least. Otherwise we end up in a situation where we need to support multiple version of sv2 every version is labelled with version 2 and it will be a lot harder then to support a bunch of well specified extensions.