Revisit AuthManager design

[sunng87]

Currently we have AuthManager as a basic gateway to authn and authz. In #186 , it also opens a connection between AuthManager and pg_catalog, which may block #189 .

I haven't got a clear idea for myself at what scope we have support for authn/authz in this library. This ideal situation is user can bring their own StartupHandler for authn, while use a decorator or interceptor for query handlers to archive authz. This approach will discouple auth concept completely from this library so we can make this library solid and generic enough for its core features.

Let me know about your ideas.

[mjgarton]

When I implemented #186 I only connected it with AuthManager because I noticed AuthManager was there already. The roles table implementation could have that connection removed and be made simpler and more hard coded for now if it unblocks #189. We can make it better again later.

I personally don't use the AuthManager capabilities, so I don't have a strong view about how that should work, but decoupling it completely from this library seems sensible.

[sunng87]

My quick idea is to define a trait say ContextDataProvider for pg_catalog, which can provide roles for pg_roles. We will also use current AuthManager as an implementation.