Create an identity abstraction for all possible API login types

Problem to solve

When authenticating to the API, a user is expected. This is determined from for example a personal access token associated with a user, or a job token, associated with the user that initiated the job.

We recently added deploy tokens as a valid way to authenticate against specific endpoints in the API (package management endpoints). A deploy token is not associated with a user, so we use PolicyActor to allow non-user objects to respond to user methods in a duck-typing sort of way.

Proposal

We should create an identity abstraction to handle all authentication types including but not limited to a user, a technical account, a bot, a collection of users (via deploy token representing project/group members).

Further details

Permissions and Security

Documentation

Availability & Testing

As this will require large changes to the authentication flow, extensive testing and security review is needed.

What does success look like, and how can we measure that?

Different authentication types can respond to the same methods and behave in the same way when authenticating. If a given auth method is implemented, we should not have create method bypasses of other models to allow it to authenticate.

Is this a cross-stage feature?

Links / references

This issue was created in response to !30332 (comment 336613753)