[WIP] Re-Implement Monitors

[mrpalide]

Fixes: #63

Changes:

• [x] reimplement dmsg-monitor
• [x] reimplement ar-monitor
• [x] combine dmsg-monitor and ar-monitor as network-monitor
• [ ] reimplement tpd-monitor

How to test:

• run integration-env test, kill one visor, check network-monitor log
• TBD [for tpd-monitor]

[0pcom]

Can you describe briefly the mechanism by which this is supposed to work?

it looks to me as though the uptime tracker is used in some way to remove dead entries for dmsg discovery.

I believe in the previous implementation, you were attempting to make transports to each of those keys in dmsg discovery with the dmsg monitor.

Both of those methods are incorrect for dmsg-discovery. The only option for dmsg may be to implement a heartbeat for dmsg discovery. In that way, the client re-registers itself and any keys may just be expired once a certain time has passed without re-registration.

One can run a dmsg client for any purpose - separately from the visor ; or even for no purpose. In that instance, there is no endpoint that can be checked externally to ensure that it is actually online, and our only concern is to have a feedback mechanism which will prevent the database of entries from expanding endlessly.

This is also the case for any long-lived dmsghttp client such as dmsgweb. There is nothing that you can check on an http client externally to see if it's online because it's supposed to interact with a server.

Unless my analysis is flawed, I suggest we drop the dmsg monitor altogether at this point.