non personal spaces need no owner

[micbar]

Description

Project spaces should not have a real user as an owner.

That fixes the bug when the space creator leaves the space and is no longer granted access to the space.

@butonic @kobergj @dragotin

Solution approach

Public links will become the new unified links. Therefore they will have a longer lifecycle than public links.
Inside a space, we need a stable way to access a public link regardless of the users which can join or leave the space at any time.

This PR assigns an owner with the spaceID as UserID and type invalid as a space owner. In this way, the public link scoped token authentication can work in the same way like inside of a personal space.

@C0rby JFYI

[butonic]

I like the concept, however, naming is hard. I don't think this is a 'virtual' user. Conceptually, it represents no user, aka nobody in unix ... well ... in unix nobody should never 'own' any files or folders ...

[micbar]

After checking the public link auth, this needs another approach.

[micbar]

@butonic @kobergj @dragotin

Solution approach

Public links will become the new unified links. Therefore they will have a longer lifecycle than public links.
Inside a space, we need a stable way to access a public link regardless of the users which can join or leave the space at any time.

This PR assigns an owner with the spaceID as UserID and type invalid as a space owner. In this way, the public link scoped token authentication can work in the same way like inside of a personal space.

@C0rby JFYI

[butonic]

While I am not happy with using an invalid user type, we can update the CS3 api with a new USER_TYPE_SPACE_OWNER ... hm maybe we should then use 8 (the next free int, which would be assigned to USER_TYPE_SPACE_OWNER) before merging this?

[micbar]

@butonic done