when a client or probe first are (re-)enabled, we can't expect to have readings
within the time window we'd normally be checking. previously we'd get false
alarms about "probe error status" etc. when this happened; hopefully no longer!
this can isolate an error for a certain probe, so that other probes can go
ahead and take their readings during each client run. that way only the bad
one is marked as "error" status by the server
i.e. this lets us keep track of when a probe becomes "high temp" and then later
if it becomes "critical high temp" we can still know how long it's been high
note that a retry is *not* attempted within a given "take readings" run.
rather, client will consider that full readings take to have failed, if any
part of it fails.
but then we keep track of type/amount of some (database connection) failures,
and will suppress logging the full error for first 3 attempts. in practice
this lets us recover from simple database restarts, and if database becomes
truly unavailable we'll hear about it shortly.
any other type of error is immediately logged on first failure.
note that a retry is *not* attempted within a given "check readings" run.
rather, server will consider that full readings check to have failed, if any
part of it fails.
but then we keep track of type/amount of some (database connection) failures,
and will suppress logging the full error for first 3 attempts. in practice
this lets us recover from simple database restarts, and if database becomes
truly unavailable we'll hear about it shortly.
any other type of error is immediately logged on first failure.
do not check readings for "archived" clients. do not consider the client
"offline" unless it has *no* current probe readings. previously we were
assuming offline if any probe readings were missing, even if some were found.
