Implement Recieving Room Shares

[gary-kim]

For #5723

Also have a version that avoids adding and extra table here: https://github.com/nextcloud/spreed/tree/enh/5723%2Fadd-database-single

[nickvergessen]

What is talk_federated_servers vs. talk_rooms_external

From my POV they could be part of existing tables?
An outgoing federation is just a new row in the attendees table with actorType federation and actorId <cloudid>

An incoming federation creates a room in the room table with token and the new field federation-server. Afterwards the individual users get their own records in the attendees table again.

this means the existing database queries are enough and we don't add another one when getting the users rooms or the participants in a room

[gary-kim]

Outgoing federation sounds good.

Incoming federations in the room table might be problematic since each new user is given a separate secret. Would it be okay to have a room per user? So if 4 users on a local server is participating in a federated room hosted on another server, it's handled as if it is 4 rooms on the local server.

We could also handle it such that each room from a remote server is a single room on the local server then the attendees table is used to keep track of the number of the token for each user that is in the room. That'd mean two new actor types, one for federated (users on another server) and one for shared (users on the local server that have gotten an incoming share).

cc @nickvergessen

[nickvergessen]

What was the plan with integration tests? Same PR or follow up?
I'd prefer to have it in here as there is no UI to test something.

[gary-kim]

This is purely receiving so it's a bit difficult to do integration tests at the moment. It's part of the share sending PR though, no worries.

[nickvergessen]

Looks good otherwise

[gary-kim]

Rebased to resolve conflict