Bring spamchecker to parity with mainline

[babolivier]

Note to reviewer:

Apologies for the massive PR size, as splitting turned out to be very non trivial (see #108 (comment))

Can be reviewed commit by commit, or through the following diffs (which exclude cherry picks and merge conflict resolutions):

• c9c1bed
• https://github.com/matrix-org/synapse-dinsic/pull/108/files/23e48a1f8ef61de97abd7a5c00b38e601fd6e9a4..ed31c6b1f8e035b520812be9ad101ae53d7525c6

First 3 commits are git cherry-picks of:

• Add a spamchecker callback to allow or deny room creation based on invites synapse#10898
• Add a spamchecker callback to allow or deny room joins synapse#10910
• Add a spamchecker method to allow or deny 3pid invites synapse#10894

The 5th commit is a git cherry-pick of matrix-org/synapse#11204.

Note to ops:

When deploying a Synapse version including this PR, a Synapse config change is required. All that's needed should be to move the config for the DomainRuleChecker from the spam_checker section to the modules one of the configuration file, since I also had to port the module to the new system. So this means this bit of configuration:

spam_checker:
    - module: synapse.rulecheck.DomainRuleChecker
      config: {...}

Should become:

modules:
    - module: synapse.rulecheck.DomainRuleChecker
      config: {...}

Note that this PR also removes support for the now useless can_only_create_one_to_one_rooms config option, but Synapse or the module won't fail if this option is kept around.

[babolivier]

Tests are expected to fail currently, since I haven't updated the DomainRuleChecker yet.

[erikjohnston]

Would it be easier to have the commits that are pure cherry-picks a separate PR? Or do the other commits unbreak stuff?

[babolivier]

Would it be easier to have the commits that are pure cherry-picks a separate PR? Or do the other commits unbreak stuff?

Definitely possible, I was thinking it would be just as simple to ignore them and review the other commits but now I'm not sure that's the correct approach. I'll close this PR and open two new ones.

[erikjohnston]

Thanks!

[babolivier]

@erikjohnston Actually, I've tried doing this, and found that things are kind of clashing because of differing signatures for callbacks with the same name between mainline and this repo (e.g. user_may_invite has extra arguments in its synapse-dinsic incarnation).

So opening a PR with just the cherry-picks means the DomainRuleChecker tests fail because the module hasn't been updated to use the new versions of the callbacks yet. And I can't seem to find a way to both make the tests work and have mypy not complain about calls not following type definitions, or mismatch between calls added in mainline and those added in this repo, etc, without making a cherry-pick-only PR result in something too messy for its own good which would be some kind of hacky mix between the spamchecker interface from mainline and the current one.

So I'm afraid I think I'll have to reopen this PR.

To help with review, these are the diffs with actual changes that aren't just cherry-picks and resolved merge conflicts:

c9c1bed

https://github.com/matrix-org/synapse-dinsic/pull/108/files/23e48a1f8ef61de97abd7a5c00b38e601fd6e9a4..ed31c6b1f8e035b520812be9ad101ae53d7525c6

I've updated the PR description to reflect this.

[erikjohnston]

Do we want to keep the changelogs?

[babolivier]

I don't think we care, we don't generate changelogs with towncrier for this repo.