Fix ev_is_active() checks on timers

If a started one-shot timer fires in the same loop iteration as
another event, but the other event precedes it in execution,
the timer's state can be "pending", but "!active" during the
other event's callback.

There were some bad assumptions that any started timer which
hadn't yet actually executed its callback was "active" sprinkled
around the plugins.  None of them appear to be of significant
consequence, although there's a remote possibility of
connect/write timeout races (data arrives just as timeout expires)
in plugin_http_status and plugin_tcp_connect leading to assert
failures only in debug builds (but no effect in non-debug).
Fix error string leak on geoip 'nets' reload failures