Path-to-resource examples in Share endpoint

[glpatcern]

Following today's meeting, I realize my own confusion with the paths given as examples in the /share endpoint, which should be corrected:

• When sending off a share, the path should be to the shared resource, nothing more, that is for example /dav/ocm/<some-uuid> (already dropping the host here).
• The receiver is expected to compose the URL as in OCM 1.0, and MAY issue requests such as PROPFIND https://<webdav-fqdn-as-advertised-in-discovery>/dav/ocm/<some-uuid>/some/relative/path/to/resource.txt, with a bearer token
• The sharing end is expected to support such "targeted" HTTP requests

I propose to amend the example to clarify that.

And at this point... We may well get closer to the OCM 1.0 principle, where the share payload contains just a sharedKey and a sharedSecret (not just the secret - the key here is really for lookup, so it ends up being logged, and the secret is the bearer token, with the option of a code), and the receiver is expected to compose the URL as:

https://<discovered-fqdn>/<webdav-root-from-discovery>/<sharedKey>/relative/path/to/resource.txt

This should simplify the ongoing work with Nextcloud, and it requires a minor amendment of Reva where we have to issue a discovery request (which we MUST do for security reasons) and store in the DB the full URL as opposed to just having it ready in the payload.

I confess I'd prefer shareKey instead of sharedKey, if we were to go this way, but we already have sharedSecret...

@michielbdejong @mickenordin @MahdiBaghbani comments?

[mickenordin]

For me I think a pr would be good, this sounds right to me, but seeing it in action with a diff would be good.