Bridge join rules (both ways)

[maltee1]

This PR bridges join rules from matrix to signal and vice versa.

restricted is bridged as ADMINISTRATOR, which is the same as for knock.
I was considering for a while whether it should be ANY (the bridge bot can invite puppets that don't match the restrictions and joining the signal group from matrix will work) or UNSATISFIABLE (A matrix user setting the join rules to restricted would probably not want random signal users to join if they don't correspond to the restrictions).
I decided that probably emulating restricted for the signal side through a relay is the best course of action, because it produces expected behavior on the matrix side and does not cause problems on the signal side. The only downside is that a relay would be required even if only logged-in users are in the room. Auto-setting the room creator or otherwise a signal administrator as the relay might be useful. If there is no signal administrator on matrix, then nobody should be able to set the join rule to restricted in the first place.
I think that as soon as there is an admin on matrix, we probably want to treat the room as a plumbed room and the remote platform should not restrict what is possible on matrix - especially considering bridging several remote platforms into the same room.
Most of these are just thoughts for future work though, I'm planning to bridge knocks at some point. Join rules only are of limited use, but a prerequisite.

[tulir]

Not sure if this should be bridged at all, it's not the same thing. Public is never the correct rule, and even knock isn't entirely correct (knocking from Matrix can't be supported, but bridging signal join requests into matrix knocks would provide a nice way to accept new members)

[maltee1]

By "not sure if this should be bridged at all", do you mean restricted join rules or everything?
Why is public never the correct rule? Aren't many rooms public? Knocking from matrix can be supported, if a portal exists. It requires a room alias to be set up on the matrix side, but the knock can be bridged to signal as join_group with a link, and accept_membership can be bridged as accepting the knock.

edit: and yes, bridging signal join request into matrix knocks was the primary reason I made this PR

[tulir]

Signal groups aren't public and the only way to do knocking/joining from Matrix would be for the bridge to store an invite link and use it even if the user doesn't actually know the link. An option for the bridge to store the link might make sense, but it can't be the default.

[maltee1]

I see. The scenario I had in mind was a matrix group that the administrator actually wants to be public and accessible on signal as well, so the invite link would be available publicly somewhere.
Correct me when I'm wrong, but isn't an unpublished matrix room alias kind of like a signal group invite link? Sure, you can publish an alias, but you can also publish an invite link (albeit with more clicks and on platforms not specific to that). The way I see it, the two are pretty much equivalent, and I don't really think it's a problem that knowing one will tell you the other (that also works both ways).
Additionally, an alias isn't created when the bridge sets the join rule to public, so the room stays effectively private until someone makes an alias. That's already possible - users joining via the alias may not be able to automatically join the signal side, but that doesn't really matter in terms of data protection.
So I don't actually see a problem in bridging public as ANY, but I do see a problem in not doing so, because there isn't another candidate for ANY.

[maltee1]

rebased on use_groupchange to use the config toggle introduced there