Monitor listen_to connection process in Notifications.Listener

[satom99]

The listen_to parameter is the registered name of the Postgrex.Notifications process that is used to listen for event notifications. That process is not monitored from Notifications.Listener. If the Postgrex.Notifications process goes down for any reason, the Notifications.Listener module does not call the private function listen_for_events/1 again. This results in a broken state, where we are no longer listening for event notifications.

The proposed changes monitor the Postgrex.Notifications process and react to a DOWN message and stopping the Notifications.Listener process with the same reason. The Notifications.Listener process is started from a MonitoredServer process, and so it is guaranteed to be restarted after stopping.

Note: the started Postgrex.Notifications process is configured with auto_connect: true and so it should (in theory) never go down. But processes should not be trusted like this.

[jdewar]

We believe we've seen this in our staging environment. Logs showed some unexplained dbconnection failures and after that point all event handlers/projectors/etc stopped receiving events. If we killed a projector, it would restart and handle all the pending events that it hadn't yet seen but, again, no new events were handled.

[drteeth]

I think I like this one, would it be easy to add a test for this?