Notifications rehaul

[glpatcern]

Main areas:

• Notification payloads are fully specified in case of file resources or shareType (user, etc.) recipients
• Request to share is now a notification
• Reshare operations are better explained, including the fact that access must always happen to the owner's server, not via third parties. At the moment, this implies that even if Bob received a share with share permission, Bob cannot send the share to Charlie right away and MUST send Alice a REQUEST_RESHARE notification, to ask Alice to share the same resource to Charlie.

Still missing:

• The format of a notification response when successful is left unspecified
• A FEDERATION_REMOVED notification is not specified, do we need it?
• The payloads of each notification type are specified in the I-Ds but not in spec.yaml. To be seen if we want to have satellite OpenAPI specs for them.

I acknowledge this is quite a large single commit. If needed I can extract the request to share part, but as it came through the editing it was not obvious to take it apart.

[glpatcern]

I shall add specific review comments to the changes proposed here, and I'm happy to receive specific feedback (I anticipate I don't like a couple of them). But meanwhile, as a preview of the proposed changes, I've updated the presentation I gave at the IETF WG meeting: please find it at https://cernbox.cern.ch/s/zEMiLaFRLJFrS4y

cc @ArtificialOwl for Nextcloud, @kobergj for ownCloud, @butonic for OpenCloud.

And a gentle reminder: during the OCM calls, as well as during the IETF meeting, we iterated on the fact that the new format has to be different, thus incompatible, from the current, undocumented formats adopted by Nextcloud and oCIS/OpenCloud, which are NOT interoperable. In other words, I call on all implementations to look into the necessary adjustments, starting from a simple check, in pseudo-code:

if notification['senderDomain'] is defined {
    parse new-format notification
}
else {
    parse old-format, implementation-specific notification
}