Update `invite_info` protocol to support multiple greeters during a user invite

[vxgmichel]

A couple of TODOs have been added to invite_info.json5:

https://github.com/Scille/parsec-cloud/blob/046db762af85815d14d381f6e0421596dd5cf240/libparsec/crates/protocol/schema/invited_cmds/invite_info.json5#L29-L62

Those changes are part of several efforts that have been done to allow any administrator to greet a new user into an organisation.

The first of those changes was the addition of the greeter id field in the claimer command as part of the new invite protocol. This was obviously useful for the shamir invite, but it will also be useful for the user invite.

Once those TODOs are processed, the protocol should be fully ready for the more powerful user invite. There remains a couple of instances in the server where the term greeter is used instead of created_by (i.e the creator of the invitation, which is now potentially different from the claimer). This in particular affects the EventInvitation, but the greeter field is only used internally in the server (the event sent to the client does not include a greeter field). That means those changes can easily be done later. Similarly, the client does not support a choice of greeter for user invite, but this can be implemented later without changing the protocol.

We should use the opportunity of the API protocol version bump to version 5 to implement those changes.

One more note: those changes also lay the groundwork for the invitation to be created by an external service instead of an organization administrator. This is possible due to the invitation creation not being cryptographically secured by a certificate. That means that any service with an administration token could create an invitation and trigger the sending of the invite email (similar to the user freeze feature). This is useful for linking parsec to an existing directory, or for parsec auth to automatically create shamir recovery invitation.

Extra question: should all this go into a separate RFC?

[mmmarcos]

TL;DR this will allow:

• A user to be greeted by an admin other than the one who created the invitation.
• An external service (with auth token) to create invitations. For example an LDAP could automatically create invitations. They still need to be validated by an admin.