feat: v1 users and groups service layer and unit tests

[keithmanville]

No description provided.

[jkglasbrenner]

Made my first pass and found some things to look at. A couple of general bullets to supplement the above in-line comments:

• We should verify that all modification service methods update the last_modified_on field in the ORM object (if one exists).
• I am having a change of mind about the logging labels, our API is very chatty by default in the logs it emits and upon reflection things we are flagged as "errors" aren't service-level errors (i.e. these aren't problems in the application logic, instead they're problems in user input/output). I think we should change most/all of these to LOGGER.debug so that people running Dioptra have the option to make the app quieter.

[jkglasbrenner]

In addition to the inline comments, we have non-functional endpoints in the groups endpoint. We should deactivate these endpoints until they're implemented.

[jkglasbrenner]

Made some changes, most things are a refactor of some kind. Still need to get the docstrings updated.

[jkglasbrenner]

@keithmanville Capturing remaining todos:

• Update the return behavior in actions.login and the auth_account fixture
• Ensure the docstrings are updated everywhere
• Ensure a commit=True option is available in every create() and modify() service method

[jkglasbrenner]

@keithmanville I've gone through and updated all the docstrings I noticed were either missing or incomplete. I also added the commit argument to all of the create and modify methods. I've opted to not add it for deletes for now, since I'm a little unsure of the consequences of allowing a delete lock to be added as part of a larger database transaction.

Finally, I did a quick test of the User and Group implementations using the Swagger Docs. I tested it against a Postgres database, everything worked as expected and the records in the database looked the way they should.

I think this is ready to merge, when I have a moment later tonight I'll squash everything one more time and get this into dev before Friday.

Also, as a heads up, I ended up having to extract the load_user method into a standalone function. I noticed it was changed to accept an integer and filter by user_id. I switched it back to accepting a string that represents a UUID and filter by alternative_id:

def load_user(user_id: str) -> models.User | None:
    """Load the user associated with a provided id.

    This function is intended for use with Flask-Login. The use of the alternative ID is
    needed to support the "logout everywhere" functionality and provides a mechanism for
    expiring sessions.

    Args:
        user_id: A string containing a UUID that matches the user's alternative ID.

    Returns:
        A user object if the user is found, otherwise None.
    """
    stmt = select(models.User).filter_by(
        alternative_id=uuid.UUID(user_id), is_deleted=False
    )
    return db.session.scalars(stmt).first()

The docstring copied above explains why its necessary to do it this way. This is also necessary to match up with this method in the User ORM class:

dioptra/src/dioptra/restapi/db/models/users.py

Lines 113 to 119 in db41860

	def get_id(self) -> str:
	"""Get the user's session identifier.
	Returns:
	The user's identifier as a string.
	"""
	return str(self.alternative_id)

See here in the Flask-Login documentation for more info: https://flask-login.readthedocs.io/en/latest/#alternative-tokens