* na-release/candidate:
vere: to 1.0
gaze: update for eth-watcher batch resuls
vere: replaces obsolete references to u3v_numb and u3A->sen
u3: adds comments to explain unusual u3v_arvo/u3v_home requirements
u3: fixes checkpoint version enforcement, refactors u3m_pave() et al
king: port the new lmdb event log changes.
u3: WIP adds a version to the checkpoint / persistent state
u3: revises "rock" format, tags jet registrations
u3: adds version number to checkpoint patch files
u3: removes obsolete members from u3_arvo
vere: removes u3A->sen references from i/o drivers
vere: implements lmdb event log format
vere: adds version to lmdb meta table, removes unnecessary jam
Previously, when the refresh-rate timer activated, and the thread from
the previous activation was still running, we would kill it and start
a new one. For low refresh rates, on slower machines, nodes, or network
connections, this could cause the update to never conclude.
Here we add a timeout-time to eth-watcher's config. If the refresh-rate
timer activates, and a thread exists, but hasn't been running for at
least the specified timeout-time yet, we simply take no action, and wait
for the next refresh timer.
Note that we opted for "at least timeout-time", instead of killing &
restarting directly after the specified timeout-time has passed, to
avoid having to handle an extra timer flow.
In the +on-load logic, we configure the timeout-time for existing
watchdogs as six times the refresh-rate. We want to set
azimuth-tracker's timeout-time to ~m30, and don't care much about other,
less-likely-to-be-active use cases of eth-watcher.
