Work from invalid jobs submitted when reconnecting to a DATUM pool; rare reconnect loop

[wizkid057]

datum_gateway/src/datum_protocol.c

Line 1606 in 3105546

if ((datum_last_accepted_share_local_tsms - datum_last_accepted_share_tsms) >= 30000) {

drops a pool connection if it doesn't acknowledge and accept any shares submitted within 30 seconds, as a sanity crosscheck.

Upon reconnection, if miners are working on work with a stale connection ID, that will will be submitted, and rejected. The above will trigger if there's no work change to valid work AND share acceptance within 30 seconds, potentially causing a reconnect loop if everything aligns to get stales in before any work change gets any accepted in. At very low and very high hash rates, this will likely not happen. There's a sweet spot of work update interval and hash rate where it's higher probability, however.

To solve:

• We need to clean=true new work to miners upon reconnection to the DATUM pool
• We need to not send work to the work to the DATUM pool that we know doesn't match the connection ID provided
• We should make sure the 30 second timeout allows for time for an actual work change (should be fine if the above items are implemented)