stratum: Add ability to map specific username suffixes to split shares

[luke-jr]

If a username contains a tilde character ('~'), the suffix following it is looked up in a mapping table specified in the configuration file.
The mapping entries specify alternate Bitcoin addresses to submit shares with, up to a specified proportion.
The worker name specified before the tilde following a period ('.'), if any, is copied to each mapped address.
Mappings may include a "" entry that assigns a split to the original username/address.
If less than 100% is assigned, the remaining goes to the address configured by mining.pool_address (without any worker name!).
If greater than 100% is assigned, only the first 100% (in random order!) will get shares distributed.

Alternative to #99 to address miner firmwares having small username length limits.

[wizkid057]

tACK

Seems fine overall for a first release. I couldn't completely break it. :)

I think the main thing might be to note potential performance impact in high-hashrate (or high share rate in a lotto config with low vardiff settings) on lower end hardware. This does seem to add significant overhead to a stratum submit, especially when testing with a dozen or so mods configured or more. Could use an optimization pass eventually, but probably fine for now as long as its noted somewhere that there's a linear performance impact when enabled. I noted virtually no performance impact when disabled.

Some notes, mostly for future reference and optimization:

• Not 100% sure on this, but it feels like the memory usage behind the mod configuration load might have a use-after-free race condition if we ever decide to implement live configuration reloading. Something that will need to be kept in mind.
• This definitely adds some non-trivial performance overhead per-share-submit in my testing when enabled. The easy-out that avoids this is fine, however, but it probably should be noted somewhere that using this could increase CPU overhead.
  • The implementation is functional, but can definitely be optimized.
  • For example, the config should probably be loaded in such a way to make the hunt per-submit as efficient as possible. The current code seems to rely on many pointers and likely fragmented memory lookups as a result, negating CPU cache benefits with the lookups and causing performance loss beyond just the added code execution time.
  • It seems like datum_stratum_mod_username could probably be optimized heavily. The ranges could be pre-sorted, and a binary search done on them to find the matching range instead of a linear search.
  • datum_username_mods_find is also a linear search... probably fine for a small number of entries, but definitely going to add significant overhead to the stratum share submission function if there are a bunch of entries, especially if the username specifies one that doesn't exist and it has to search them all. probably needs an on-load sort as well with a binary search to bring from O(n) to O(log2(n)).
• Perhaps later there should there be some on-load validation on the Bitcoin addresses used in the config, similar to the pool_address? Seems like this would make it easy to avoid that particular footgun.