fix: graceful shutdown

[LePremierHomme]

An attempt to solve #1668.

Various fixes were made to prevent delays in shutdown:

• Revoke connection retries of closed peers.
• When using Tor, first create a plain socket connection with the local service, before passing it to the SOCKS client. This enables us to keep track of the raw socket while SOCKS connection to destination is pending, and to close it on shutdown.
• Keep track of the reachability verification dummy peer, so it can be closed on shutdown.
• Keep track of ConnextClient's pending HTTP requests, and abort them on shutdown (besides the critical ones). A jest test was added, but it's using an HTTP client mock (which works according to nodejs documentation). This is not ideal, but I thought that using a real HTTP client/server for this test would be an overkill.
  This behaviour still need to be manually tested.

Pending swaps are still expected to (intentionally) cause delay in shutdown.
There might be other issues which cause a delay which I haven't encountered.
So any help in testing would be appriciated. Please paste your logs here (even if it works).

To launch via xud-docker:

$ bash ~/xud.sh -b fix_shutdown

[sangaman]

Very nice, just see one suggestion about how we track/reference pending connext requests.

[ghost]

Looking forward to getting this in... 👍

[kilrau]

Fix is in, could you give this another look? @sangaman

[sangaman]

Looks great now. This is a nice approach and good sleuth work to identify these issues, I'm expecting this to make a real difference.

[rsercano]

Another case (don't know if we want to stay it like this) is that somebody calling streamorders or new stream grpc call subscribe alerts (#1984) then unless stream is closed xud is not being closed.

Ignore if this's intentional.

[kilrau]

I think we should to close streams as part of the shutdown procedure. If that's not the case, want to take care of it as a separate PR? @rsercano

[rsercano]

I think we should to close streams as part of the shutdown procedure. If that's not the case, want to take care of it as a separate PR? @rsercano

Sure as long as @LePremierHomme doesn't want to address it, I can check too.

[kilrau]

Definitely not as part of this PR, so go ahead 👍

[ghost]

Works very nicely for me. Thanks for this!

[rsercano]

Definitely not as part of this PR, so go ahead 👍

After digging into this, I realized this has already been addressed for streamorders and my bad not to handle on subscribealerts by adding stream to current list, Im now adding it and should be handled on close.