MSC3926: Disable server-default notifications for bot users by default

[Half-Shot]

Fixes matrix-org/matrix-spec#1327

Rendered

[clokep]

Combine the 1st & 3rd paragraph since they're both about generating notifications:

Suggested change

	In the case of the latter two, it's not useful to calculate notifications because the majority of
	application services and bots do not read notifications.
	Notifications are "cleared" when a read receipt is sent into the room, but neither bots or application
	services send read receipts in all cases. This can very easily lead to a lot of wasted disk space in some
	implementations.
	There is also the case that each notitification rule will take some amount of CPU time to process, which
	is entirely wasted if the account doesn't check notifications.
	In the case of the latter two, it's not useful to calculate notifications because the majority of
	application services and bots do not read notifications. This leads to wasted processing time
	as the homeserver will evaluate push rules to generate notification counts which will never
	be read.
	Notifications are "cleared" when a read receipt is sent into the room, but neither bots nor application
	services send read receipts in all cases. This can easily lead toa wasted disk space or performance
	issues if notifications are never cleared.

[clokep]

This is not backwards compatible, technically.

[clokep]

Suggested change

	When set, the homeserver MUST disable all rules defined in [predefined-rules](https://spec.matrix.org/v1.4/client-server-api/#predefined-rules),
	effectively thereby disabling the calculation of notifications. The user will still be able to enable these notification rules if they so wish.
	When set, the homeserver MUST disable all [predefined push rules](https://spec.matrix.org/v1.4/client-server-api/#predefined-rules)
	for this user by enabling [the `.m.rule.master` rule](https://spec.matrix.org/v1.4/client-server-api/#default-override-rules). The user will still be able
	to enable these notification rules if they so wish.

[clokep]

Suggested change

	Instead of adding a flag, the homeserver could instead only start tracking notifications when the user
	/syncs. This might help with cases where users are registered but never used. It would also help with
	application services where users never sync. However, this would still cause notifications to be calculated
	for traditional `/sync`ing bots. Overall an explicit option at registration time seems more preferable.
	Instead of adding a flag, the homeserver could instead only start tracking notifications when the user
	makes a `/sync` request. This might help with cases where users are registered but never used. It would also help with
	application services where users never sync. However, this would still cause notifications to be calculated
	for traditional `/sync`ing bots. Overall an explicit option at registration time seems more preferable.

[clokep]

Suggested change

	Bots and integrations could instead explicitly disable all rules on signup, rather than expecting the
	Bots and integrations could instead [explicitly enable the `.m.rule.master`](https://spec.matrix.org/v1.4/client-server-api/#predefined-rules)
	rule on signup via a [`PUT /pushrules/global/override/.m.rule.master` request](https://spec.matrix.org/v1.4/client-server-api/#put_matrixclientv3pushrulesscopekindruleid),
	rather than expecting the

[clokep]

Suggested change

	While this MSC is unstable, `enable_predefined_push_rules` should be called `org.matrix.mscXXXX.enable_predefined_push_rules`.
	While this MSC is unstable, `enable_predefined_push_rules` should be called `org.matrix.msc3926.enable_predefined_push_rules`.

[turt2live]

fwiw, from title alone: this would be a very welcome change. t2bot.io, which offers largely bridge traffic, has disabled push processing on synapse to speed up event handling paths - it feels like a natural next step to improve (at least) CPU usage for other massive bridge deployments.

[Half-Shot]

I understood from the Synapse team that they check users against the AS namespaces and short-circuit notification checks entirely. While that's fine, it's a bit divergent from the spec and we should seek to make it explicit/official.