telemetry: Add mutex to avoid push during recalc and other races

[Spudz76]

Add simple locking to telemetry class, since both push and calc methods modify the data buckets and pointers, this avoids race conditions and bucket corruption.

Hoping this solves occasional "missing stats" or inaccuracy that could not be tracked down to anything but "thread timing mystery". It does seem to standardize my hashrates as shown which I take to mean it's more accurate.

Regardless it doesn't seem to hurt.

[Spudz76]

Bisecting but this patch might hang Windows+CUDA exiting after benchmark. That or Windows+CUDA no longer exits after benchmark mode? It does in OpenCL or just CPU modes.

As far as I understand the mutex should destruct just fine in any state, so I'm not sure why this would hang the main executor loop. But also there seems to be some locking inside executor so this may be superfluous. I was previously unsure if reporting events were locked vs the incoming pushes in all cases.

Also stats are accurate (match pool shown rate exactly), running this on every one of my current XMR miners (all CPUs). I do believe they are more stable and accurate.

[psychocrypt]

Bisecting but this patch might hang Windows+CUDA exiting after benchmark. That or Windows+CUDA no longer exits after benchmark mode?

Does this means this PR can currently not used together with CUDA?

IF so we need to fix that first.

[Spudz76]

Confirmed my build does not exit even without this patch, so it is GOOD.

Reasonably sure there are several missing win_exit() calls in the benchmark section causing this other behavior. But does not particularly answer how it exits fine to prompt (no press key) under the other backends... anyway it's definitely not this.

[Spudz76]

example of rock solid hashrates from a rig running for the last day or so:

HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |   17.7 |   17.7 |   17.7 |  1 |   17.7 |   17.7 |   17.7 |
|  2 |   17.7 |   17.7 |   17.7 |  3 |   17.7 |   17.7 |   17.7 |
|  4 |   17.7 |   17.7 |   17.7 |  5 |   17.7 |   17.7 |   17.7 |
|  6 |   17.7 |   17.7 |   17.7 |  7 |   17.7 |   17.7 |   17.7 |
Totals (CPU):   141.8  141.8  141.7 H/s
-----------------------------------------------------------------
Totals (ALL):    141.8  141.8  141.7 H/s
Highest:   142.0 H/s
-----------------------------------------------------------------

This same rig without this mutex always had variances everywhere (+-0.7 per thread)
Pool side 6h avg hashrate is the same perhaps better but unknown if that smoothness is due to luck variances. However the pool side rate matches much closer to the report while before it showed a bit high in the report (especially the 10s column) but lower on the pool (15m was much closer to reality).

HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |   17.8 |   17.8 |   17.5 |  1 |   17.9 |   17.9 |   17.0 |
|  2 |   17.9 |   17.9 |   17.0 |  3 |   17.9 |   17.9 |   17.0 |
|  4 |   17.9 |   17.8 |   17.3 |  5 |   17.9 |   17.9 |   17.3 |
|  6 |   17.9 |   17.9 |   17.4 |  7 |   17.9 |   17.9 |   17.3 |
Totals (CPU):   143.0  142.9  137.7 H/s
-----------------------------------------------------------------
Totals (ALL):    143.0  142.9  137.7 H/s
Highest:   143.1 H/s
-----------------------------------------------------------------

non-AES cpu