Make uploads work with tus and through gateway

[ishank011]

This PR makes uploads work with tus and uploads and downloads through the reva data gateway. Reva also provides the option to configure storage mount paths, which is now also handled.

With the default ocmd-server-1.toml config,

WOPI_STORAGE=cs3 python3 test_storageiface.py
...........
----------------------------------------------------------------------
Ran 11 tests in 0.389s

OK

There was one bug with both tus and gateway enabled, which will be fixed by this.

[glpatcern]

Very nice, thanks for this. I'd suggest a minor addition: add to the reference config file https://github.com/cs3org/wopiserver/blob/master/wopiserver.conf this extra parameter with a one-line comment about it.

And a more general question: what is the relation between the multiple Reva mount points and the storage ids?

[ishank011]

@glpatcern thanks for the review! Added the reference in the config file.

Mount paths in reva can be used to restrict access to a set of resources for different users. For example, we usually have two storage providers running in reva. One can be mounted at /home and the other at /reva. All requests with paths starting with /home would be redirected to the logged-in user's namespace. If the user wants to access a file shared with him by another user, this won't be possible through this as the file won't be present in the current user's namespace. So such requests would be identified internally and redirected to the other storage provider which would have access to all the resources. Since both the storage providers point to the same root directory, they share the storage ids

[ishank011]

And it was decided some time back that the home storage provider should always be mounted at /home instead of / https://github.com/cs3org/reva/issues/601. I've also updated the same in the ocmd toml file.

[glpatcern]

Thanks for the details and the reference, good to know.

So we can assume that /home will always be present, and possibly others too depending on the deployment, right? In that case, we should probably make the option uncommented with its default value /home. At the same time, the question is whether this should rather be a per-request parameter rather than a configuration option (or maybe I missed something). What do you think?

[ishank011]

Yes, ideally requests can indeed go to different mounts. Requests to shared resources would be mounted on /home only (e.g. /home/Shares/shared_file.md), but we can have mounts such as /eos/home and /eos/project. It depends on what wopi knows about the reva mount paths. If we can assume that requests from wopi would always have either of these supported prefixes then we can get rid of this config in the first place. If not, we would need these for each mount.

[glpatcern]

For the record, we agreed to remove revamountpath from the production config, given that Reva will dispatch according to its configuration. Nevertheless, the test suite has been extended to support this concept (with /home as value); this is similar to how the xrootiface.py layer used to work (and still has code for that, though it's not used in production any longer).

That said, tests pass, therefore I'm merging this.