The primary motivation for converting API keys so that they are explicitly
linked to user accounts is to provide some method for TrueNAS Connect
to use tie in to local or directory services accounts to a credential
that is persistently stored in the TrueNAS Connect keychain.

The legacy API key mechanism was insufficient for this purpose because
the mismatch between user accounts and API keys could lead to
administrators retaining NAS access after account deletion, expiration,
or locking. For more in-depth context and reasoning please refer to the
internal design document NEP-053.

For this purpose, this commit makes the following changes:
1. Legacy API keys are migrated to a user_identifier LEGACY_API_KEY
   which is automatically linked to the root, admin, or truenas_admin
   account depending on server configuration.
2. If the legacy API key granted less than FULL_CONTROL, then the
   API key is migrated with a `revoked` state so that the system
   administrator has an opportunity to review and generate a new
   key and/or service account that provides the correct level of
   access.
3. API key authentication now passes through libpam.
4. user.query results now include an `api_keys` key that contains a
   list of IDs for API keys that exist for the user.
5. Authenticated users with READONLY_ADMIN privilege or greater are
   able to create and manage their own API keys.

During development of this new feature, it was determined that the
original API keys were written with insufficient hashing rounds leading
to the following changes:

6. On successful authentication the stored hash of any LEGACY_API_KEY
   is automatically upgraded to a newer sha512-based standard with
   significantly increased hashing rounds.
7. Dependency on the passlib library was removed.

Since libpam is now used for all non-token authentication methods, a
new auth login endpoint (auth.login_ex) was added to middleware to
facilitate future enhancements for challenge-response authentication
mechanisms. Authentication via username + password + OTP token has been
converted to this new standard. This new endpoint is more closely
aligned with standards and requirements in NIST SP 800-63B. In summary
the following changes were made:

8. An AuthentationContext dataclass was created to house a middleware
   session's PAM context and associated information. An instance of
   this is stored in the session's App object.
9. A new endpoint auth.login_ex was added that is expandable and is
   aware of the server's configured "authentication assurance level".
10. Existing login endpoints (auth.login, auth.login_with_api_key,
   auth.login_with_token) were converted to wrappers around
   auth.login_ex.
11. Initial implementation of session lifetime and inactivity guidelines
   for different authentication assurance levels was added.
12. Challenge-response workflow for username + password + OTP token
   implemented with associated tests.