This reverts commit e05616b327.
We are reverting the since command for multiple reasons.
1. The roomMemberTest that this commit brings has an `it` block ("RoomMemberManager counts correctly when we actually join/leave/get banned from the room")
that now fails in an infinite loop and we struggle to understand how it ever passed.
> essentially they assert that Mjolnir is in the room here https://github.com/matrix-org/mjolnir/blob/main/test/integration/roomMembersTest.ts#L303
Which is great, but they've never joined it or have been invited.
https://github.com/matrix-org/mjolnir/blob/main/test/integration/roomMembersTest.ts#L302 but then we also assert that there's only one person in the room, but this can't be Mjolnir because Mjolnir didn't
create these rooms https://github.com/matrix-org/mjolnir/blob/main/test/integration/roomMembersTest.ts#L273, yet they're checking that Mjolnir is indeed there.
The loop in question is also over complicated and hard to read https://github.com/matrix-org/mjolnir/pull/225/files#diff-67e09dce96f975b2df641d3c600f60f48aeeb9e54a472b612bce90535b4aa0e4R285-R295
Should have been written like this.
```
while(!roomIds.each(roomId => this.mjolnir.protectedRooms[roomId])) {
await new Promise(resolve => setTimeout(resolve, 1_000));
}
```
2. The RoomMemberManager is broken even after fixing the test (fixing so that it fails "normally" without getting caught in the loop by changing the setup code) and we have decided is not worth fixing yet.
This is because it is complex & the manager only knows about joins that have happened since Mjolnir has started syncing, this has proven un-initiative to Mjolnir users already.
Possible solutions are using the planned the full rolling room member/state cache (https://github.com/matrix-org/mjolnir/issues/273) or using `/messages` with a filter for member events for the `!since` command, since `/messages` is "chronologically" ordered.
The reason we want this is so that people do not forget to change the version number in the synapse module.
The precedent is that the version number has been 0.1.0 since the begging until now.
While this solution does mean that there may be new version of the module where
nothing has actually changed, this is still better than not changing the version at all.
Another version scheme for the module would be inconsistent to
the git repository tags and that has the potential to cause much more confusion
than "blank" version bumps.
If this is a problem, then antispam must be extracted to another repository.
In order to test this, run `yarn version --patch` observe the changes with `git log` and `git diff HEAD~`,
then YOU MUST delete the tag with `git tag --delete vd.d.d` when you are finished.
* more robust
