Use the JupyterHub User with UserInfo on NativeAuthenticator

[leportella]

As exposed by @minrk on issue #26 it is not the best approach to use the JupyterHub orm on NativeAuth. However, to use the /admin endpoint for user management, it would be necessary to connect information between users. At least I think so. What's you thoughts on this? @minrk @yuvipanda

[yuvipanda]

Hmm, the reasons I wanted to use the same ORM setup are:

1. To prevent having to keep multiple databases in sync (especially around user cascading deletes, and recreating users with the same name)
2. To prevent admins from having to set up different databases - re-using has similar api stability problems because we don't support prefixes on the JupyterHub side (afaik). This is not as big a deal though.

I used a separate db for FirstUseAuthenticator, and ran into a score of issues related to (1) - especially around propagating user deletions. I also see what @minrk is suggesting about medium-longer term API compatibility.

@minrk do we have some way to propagate user deletes across? I think with that we should be ok.

@leportella for the endpoint, I think we need to call it something like /nativeauth/admin or some such - or more specifically, multiple ones (/nativeauth/authorize-accounts, /nativeauth/reset-password, etc).

[minrk]

It's not an urgent issue (it will only come up on possible hub upgrades), so I wouldn't worry about it too much to start. But it is raising my "private api" flag. Using e.g. the db_url config to talk to the same database does seem like a sensible solution to avoid maintaining multiple databases, but I am reticent to recommend 'relations' on the existing tables and especially the ORM API, since I want to, among other things, reserve the right to move away from sqlalchemy when we are looking at high-availability hubs.

I think the only answer we currently have for authenticators storing state related to users is the auth_state field. This is covered by the deletion, etc., but I think there isn't a good answer to retrieving this data during the authenticate process.

As for deletion cascades, I would think the existing Authenticator.delete_user hook would suffice. What cases are there where this doesn't work?

Maybe we can take this opportunity to enumerate some of the things that Authenticators with external state may need, and codify them at the Python level. That's how we got auth_state, and it sounds like there's more that we can add. I'd love to get to a point where Authenticators and Spawners don't even have direct access to the database connection.