Optional Terms Of Services APIs and libparsec support

[touilleMan]

Changes:

• an organization can be configured with a EULA
• a default EULA can be provided in the server configuration for spontaneously created organization
• authenticated cmds now check that the author has accepted the EULA, if not an HTTP 463 error is returned
• a new cmds family is introduced: the "eula" cmds which is similar to to the authenticated cmds family but doesn't check for the EULA to be accepted.
• the eula cmds family exposes two commands eula_get (to retreive the EULA url that should be displayed to the user) and eula_accept (to accept the EULA, once done the authenticated cmds can be used)
• if organization's EULA is updated, then the user using authenticated API will get 463 until they accept the new EULA
• if organization's EULA is removed, then user can use authenticated API no matter if they have accepted or not the previous EULA
• From the bindings point of view, client_get_eula and client_accept_eula are now part of libparsec

What is left:

Currently libparsec_client doesn't correctly handle HTTP errors coming from the server (see #8472 ).

This means the HTTP 463 error coming from the server in case the EULA hasn't been accept is currently translated into an internal error (instead of being a proper dedicated error).

[AureliaDolo]

I don't get exactly why eula is it's own kind of commands. It's because it's only part of the auth process ?

[AureliaDolo]

@touilleMan see #8513 for the old invitation system artifacts

[touilleMan]

I don't get exactly why eula is it's own kind of commands. It's because it's only part of the auth process ?

@AureliaDolo the issue is the authenticated cmds family checks that the user has accepted the Terms Of Service

So the commands to retrieve and accept the Terms Of Service must go through a different cmds family that does the same authentication checks, except for the acceptation of the Terms Of Service part.

[mmmarcos]

As discussed with @touilleMan we should add a (minimal?) RFC describing how this works

[AureliaDolo]

Why is this mock needed ?

[FirelightFlagboy]

It's used for testing the crate itself

[touilleMan]

Yes, the libparsec_serialization_format crate generates in its proc macros some code that makes uses of the types in libparsec_types.
So that means libparsec_serialization_format's tests requires libparsec_types as dependencies, but this is cumbersome (don't remember the specifics, but I guess it has to do with circular dependencies).
So instead of directly relying on libparsec_types, the generated code refers to something like super::libparsec_types. This way the user of the proc macro can define whath is libparsec_types should be:

• a mock (the code you were pointing out) in case of libparsec_serialization_format's tests
• the real libparsec_types crate for all other cases