Add authorization relations in proto

[eleftherias]

In this approach we enumerate all of the roles a user can have with an entity (in this case only project).

If our API evolves to have finer grained authorization, then we can add values to ObjectOwner to describe the entity type we are requesting authorization for.
For example, if we add a relation where a user can "create" a repo, then we can add an OBJECT_OWNER_REPO enum value to ObjectOwner and reuse the Relation.CREATE value.

Alternatives considered

Only specifying the resource type we are requesting access to in the rpc definition and deriving the relation, either by:

• Getting the HTTP verb and mapping it to the relation (e.g get -> get, post -> create)
• Using our naming convention to derive the relation (e.g if the method starts with List then it's a get relation)

rpc ListArtifacts (ListArtifactsRequest) returns (ListArtifactsResponse) {
    option (google.api.http) = {
        get: "/api/v1/artifacts/{provider}"
        additional_bindings {
            get: "/api/v1/artifacts"
        }
    };

    option (rpc_options) = {
        auth_scope: OBJECT_OWNER_PROJECT
        resource: ARTIFACT
    };
}

Both of these seem fragile, because they rely on us following certain conventions. In the case of something as important as authorization, I would rather be explicit, even if it's verbose.

[JAORMX]

FWIW, on first thought, I'm more keen on the approached proposed by this PR than the alternative documented in the description

[JAORMX]

Giving this some thought, I do like the proposed approach more than the described alternative. Explicit is better than implicit and it seems to me like it's less error-prone. This will also help us handle some edge-cases such as the profile status (which needs a dedicated relation IMO).

[JAORMX]

awesome! great work!

[evankanderson]

Not sure if we also want to reserve the names -- since these options don't show up much on the wire proto and don't mean anything to clients, I'm okay with being faster & looser here.

[eleftherias]

Yeah I was wondering if it's even worth reserving the field numbers here, since it's not something the clients use.

[evankanderson]

These are temporary until we complete the OpenFGA switchover, right?

[eleftherias]

Yes, that's right

[eleftherias]

I'm fairly sure they don't serve any purpose now either, since currently users are always owners of their single org. They can likely be removed even before the openfga switchover.