[Auth0] Allow redirecting to custom URL after logout

[yuvipanda]

This can't be just done by setting logout_redirect_url unfortunately, as client_id is also required to be passed in here (see https://auth0.com/docs/authenticate/login/logout/redirect-users-after-logout).

While that could be done via a callable, this is much cleaner to do.

[yuvipanda]

I was experimenting with this today, and here are my results:

	client_id specified	client_id not specified
returnTo specified	returnTo is just ignored, user is redirected to whatever is the first url specified in the logout settings	returnTo is just ignored, user is shown a page that just says 'OK'
returnTo not specified	returnTo is just ignored, user is redirected to whatever is the first url specified in the logout settings	returnTo is just ignored, user is redirected to whatever is the first url specified in the logout settings

Ok so that's a bit redundant, but at least what I've discovered so far seems to be that returnTo is ignored, and you must specify client_id at which point you get redirected to whatever was first in the approved list of logout URLs. This seems contrary to what they have documented

@GeorgianaElena from your links, it's possible that perhaps this logout url was added by the community to the wrong location. I'll follow up and debug some more. It would be nice to not need this!

[yuvipanda]

From my experimentation in https://github.com/jupyterhub/oauthenticator/pull/722#issuecomment-1922427154, I've noticed that you must specify client_id for anything to work at all. This completely contradicts Auth0's own documentation.

However, client_id is not actually public information - it is available to anyone who clicks the 'login' url. So we don't actually need to protect this. As such, users can get the desired behavior by using the existing logout_redirect_url behavior, and specifying ?client_id directly. This is what I've now documented as we should do with 2i2c (https://github.com/2i2c-org/infrastructure/pull/3883/files#diff-645ca1737a635e7140f9811524d2612c4ff4573f6b0314e5bff33087adb17e12R72).

With that, I think it's ok to close this PR!