Decouple spaces API from storage

[gmgigi96]

The spaces API are currently coupled with the storage. This PR decouple them from the storage, allowing a more flexible implementation.

[labkode]

@gmgigi96 looks good to me to split the spaces and the storage api into two separate entities as the spaces sit on top storage and have functionalities on top of it.

This is a breaking change because of a new API, however it should be straighforward at the code level to change as the messages are the same.

@cs3org/owncloud-team please review.

[micbar]

Hmm, from my pov I consider a storage provider which has no spaces support as an invalid implementation.

[labkode]

@micbar reva@master does not have Spaces support and is a valid implementation :)

[gmgigi96]

Hmm, from my pov I consider a storage provider which has no spaces support as an invalid implementation.

@micbar I think where you store spaces is just a matter of implementation detail. For us is a DB, for you the storage itself. That's why this need to be separated.

[micbar]

@micbar reva@master does not have Spaces support and is a valid implementation :)

Correct. But as I understood you some years ago, that should only be temporary. You had the plan to converge with reva edge. Did this plan change?

[labkode]

@micbar plan is to converge on web only, and look at future options later.

[micbar]

@micbar I think where you store spaces is just a matter of implementation detail. For us is a DB, for you the storage itself. That's why this need to be separated.

I think you are missing the details. Every Stat call or every Call to the storage provider needs to implement the spaces semantics. Resources are referenced by <StorageID><SpaceID><OpaqueID>.

Reva master does only path based requests. On Reva Edge, Spaces are a basic architectural concept of total decentralization. Reva Master has the concept that there is a global path which is the same for everybody. These two concepts are different in its core.

Maybe I am the only one who is concerned about diverging too much.

@butonic @dragotin @kobergj @dragonchaser