Instead of providing a (unit path), allows for (list path), which better
supports the "update to path and subpath cases".
For example, if /things wants updates about everything, and
/things/specific wants updates about the specific thing, they'll both
need to receive a %fact when the specific thing changes.
Previously, these would have been two separate moves. Now, gall handles
the multi-targeting for you.
When configuring a watchdog on a path that already exists, we now
"overwrite" it, meaning we throw away all history and trawl the node
for logs again.
If the only config change is the url, however, we silently modify it,
and simply use it "from this point onward".
This matches the behavior of the original azimuth-tracker.
In order to give an initial response to incoming subscriptions (without
resorting to retrieving that data from chain again) we now store event
log history in state.
Instead of discarding pending-logs entirely after sending out updates,
we add them to the watchdog's history.
Just like pending-logs, we remove from the head during a rewind (though
not before exhausting the pending-logs).
Kicks the update timer on application start, then sets a new timer
whenever it's awoken. This aims to ensure eth-watcher never stops
looking for updates periodically.
Uses the logic existing in azimuth-tracker to implement a new
eth-watcher, which can look at Ethereum nodes for _any_ events, as
opposed to exclusively a subset of the Azimuth contract's events.
Azimuth-tracker will be reimplemented as a dependent of this in
forthcoming commits.
These were deprecated in favor of azimuth-tracker in #1320.
(Azimuth-tracker, however, isn't a general-purpose Ethereum log watcher
tool. Commits to transform it into a more broadly useful tool are
forthcoming.)
