Harden jupyter-remote-desktop-proxy against reconnects

[consideRatio]

Whenever we disrupt ingress-nginx that routes traffic, for example during monthly upgrades of the helm chart or similar, we disrupt users working against a remote desktop UI (QGIS etc). When that happens, they won't get re-connected and have to refresh their browser manually.

I'd like us to fix this known issue before we get reports about it from support that prompts investigations and additional work that we could have avoided.

The key thing here is to get functionality from jupyterhub/jupyter-remote-desktop-proxy#81 to land in a release.

[yuvipanda]

I unfortunately don't have time in the next few weeks to continue that PR. From talking to the folks who use QGIS right now, this also isn't that critical and should not block a 2.0 release of that project. The most critical issue for them is finding ways back to the control panel and what not, which is provided by PRs that have already been merged but not deployed yet.

[consideRatio]

The initial connection attempt often fails currently (at least for me, may be ping dependent), and whenever we merge PRs bumping ingress-nginx like in #2067 recently, users need to figure out they should reconnect manually by refreshing.

I could also pick this up - I think its a priority to get done before we are asked via support about it.

[yuvipanda]

I helped someone from the NASA VEDA community complete this with review work! jupyterhub/jupyter-remote-desktop-proxy#112