Set required proto fields for rules and invitations

[eleftherias]

Summary

Ref #4952

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[coveralls]

coverage: 55.225% (-0.006%) from 55.231%
when pulling 43d6d0c on eleftherias:openapi-roles-invitations
into 719d417 on mindersec:main.

[evankanderson]

This looks like it improves the swagger output so a general 👍 , but one concern about invitations.

[evankanderson]

Sorry for approving the other PR, it turns out that REQUIRED applies to requests, but it's not clear what it means for replies.

https://google.aip.dev/203 is probably a good reference here, despite being Google-specific. In that context, it means:

A field should only be described as required if either:

• It is a field on a resource that a user provides somewhere as input. In this case, the resource is only valid if a "truthy" value is stored.
• When creating the resource, a value must be provided for the field on the create request.
• When updating the resource, the user may omit the field provided that the field is also absent from the field mask, indicating no change to the field (otherwise it must be provided).
• It is a field on a request message (a message that is an argument to an RPC, with a name usually ending in Request). In this case, a value must be provided as part of the request, and failure to do so must cause an error (usually INVALID_ARGUMENT).

We define the term "truthy" above as follows:

• For primitives, values other than 0, 0.0, empty string/bytes, and false
• For repeated fields maps, values with at least one entry
• For messages, any message with at least one "truthy" field.

So ListRoles is probably required here (as the user themselves should have a role), but invitations would not be because the list of outstanding invitations might be zero-length.

[eleftherias]

Empty lists are tricky because some languages consider them truthy and some don't.
From a typescript perspective, an empty list is truthy and different than a nil list.
In the generated typescript type, setting a list field in a response as REQUIRED means it's not optional, and the client can safely do things like get the length, or iterate over it.
If we didn't set the field as required the client would have to perform a null check before using the field.

[evankanderson]

Oh, interesting! it sounds like this is a difference between swagger semantics and proto semantics. TIL!

[evankanderson]

See above, probably not required.