Update meta repository (main)

[openslides-automation]

Triggered by commit 5eb31b946e9a9aea2470597fde7ae5ec2e6a5da1

[ostcar]

@luisa-beerboom Is there anything I have to do in the autoupdate-service? Does the restrictor has to change, when the flag is set, or is it only for writing?

[luisa-beerboom]

See client issue OpenSlides/openslides-client#3622 for context
If this setting is set to true for a meeting, meeting-internal data should generally not be visible to outsiders.

Generally speaking, in any place where meeting permissions are necessarily required to see the model or certain fields, superadmins should no longer be implicitly assumed to have permission while this setting is turned on.

Outsiders should still be able to see the meeting itself and whether a user is a member, but not any other relevant internal data.

Now: I do not know, whether any more of the meeting model should be specially restricted away. I imagine that vast parts of what we consider the settings might need to be locked away.
In the end, I think this'll need commentary from someone more up-to-date with the client-side of things.

I've asked @Elblinator to do the appropriate conceptualization work with @MSoeb .
They should be back to give the appropriate information in time.

Also I can imagine that this is going to be a lot of work. It may be a good idea to merge this PR for the sake of meta repo consistency and then work on the restrictor in a separate PR.
The feature wont be functional until the client is updated anyway, which I imagine will take some time.

As for what I can definitely say:
If you implement this, you may want to consider what needs to be done for OpenSlides/OpenSlides#6756 as well. The issue is somewhat similar, although more personal (since it only affects a specifically selected user) and more restrictive (since the meeting should not be visible at all to those that are locked out.

[Elblinator]

The spefications what exactly we need from the autoupdate will be written in it's own Issue soon
This PR can be merged independent from that Issue

[ostcar]

To change the visibility of the superadmin is a fundamental change that has to be discussed in detail.

Currently, the superadmin skips the restriction and there are no negative restrictions. If we want to introduce this, the superadmin has to be handled as any other user. In this case, we have to look into any restriction mode there is.

[ostcar]

We merged this PR to have the same meta repo. If and how this gets implemented in the autoupdate service is something else.