ESP8266 Re-subscribe and Auth when connection drops

Occasionally the conenction will drop and re-connect.
The issue is that the connrection never re-subscribed and Authorized to the pool after that reconnection.

This leads to shares being submitted and and receiveng the following response:

03:29:43.307 > [I] Miner: [0] > [2495007] > 0x06135197 - diff 0.000022916033
03:29:43.307 > [I] Network: >>> {"id":1871,"method":"mining.submit","params":["wmikrut.ex1","2495007","206351","65fe5606","06135197"]}
03:29:43.323 >
03:29:43.338 > [I] Network: <<< [mining.submit] {**"error": [-2, "Connection is not subscribed"**, "Traceback: : Connection is not subscribed\nstratum\\services.pyo:81:call\ntwisted\\internet\\defer.pyo:139:maybeDeferred\nstratum\\services.pyo:78:_run\ntwisted\\internet\\defer.pyo:1237:unwindGenerator\n--- ---\ntwisted\\internet\\defer.pyo:1099:_inlineCallbacks\nmining_libs\\stratum_listener.pyo:181:submit\n"], "id": 1871, "result": null}
03:29:43.370 > [I] Network: Share accepted
03:29:43.370 > [I] Current: Hash accepted: 1694

The mining.submit accepts the request in network.cpp @ 302
else if (strcmp(type, "mining.submit") == 0)
{
l_info(TAG_NETWORK, "Share accepted");
current_increment_hash_accepted();
}

What we need in that statement is a check of the error code, when not null and is a specifc error code (-2) or the text "Connection is not subscribed" to call the Subscribe and Auth functions and skip reporing the Share was accepted because it was actiually discarded by the pool.

Start in network.cpp around line 302, where mining.submit responses are handled, and trace the existing Subscribe and Auth entry points. Reproduce or inspect the reconnect path and verify that a -2 or "Connection is not subscribed" response triggers re-subscription and authorization without counting the discarded share as accepted.

Written by the indexing model from the issue text.