feat(push): add experimental support for MSC3768 (in-app-only notifications)

[Johennes]

This adds experimental support for MSC3768 by introducing the push rule action NotifyInApp and a room notification mode that is similar to mentions & keywords but notifies in-app rather than muting other notifications.

• Public API changes documented in changelogs (optional)

Signed-off-by:

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.92%. Comparing base (92192c5) to head (c3a694c).
⚠️ Report is 49 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5441   +/-   ##
=======================================
  Coverage   88.92%   88.92%           
=======================================
  Files         333      333           
  Lines       92267    92311   +44     
  Branches    92267    92311   +44     
=======================================
+ Hits        82051    82091   +40     
- Misses       6374     6378    +4     
  Partials     3842     3842           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

CodSpeed Performance Report

Merging #5441 will not alter performance

_{Comparing Johennes:johannes/msc3768 (c3a694c) with main (872713c)}

Summary

✅ 31 untouched benchmarks

[bnjbvr]

Interesting MSC. How can it be used, right now, by an embedder? Is everything already wired up, so that timeline items would be marked as notifying the user if this rule is set?

I would also like to see some tests for the new expected behaviors, please, and at both the base, SDK, and UI layers, to at least smoke-test the behavior is correctly implemented.

[bnjbvr]

nit: maybe we don't need a cfg_if here? suggestion modulo rustfmt. I think the outer block is needed because one can't put cfg guards on statements, so we need a fake expression statement to make it work. But this might be worth checking without the outer block, in case it works too.

Suggested change

	cfg_if! {
	if #[cfg(feature = "unstable-msc3768")] {
	if !rule.triggers_remote_notification() {
	// This rule contains a `NotifyInApp` action.
	return Some(RoomNotificationMode::MentionsAndKeywordsOnlyTheRestInApp);
	}
	}
	}
	#[cfg(feature = "unstable-msc3768")]
	{
	if !rule.triggers_remote_notification() {
	// This rule contains a `NotifyInApp` action.
	return Some(RoomNotificationMode::MentionsAndKeywordsOnlyTheRestInApp);
	}
	}

Also, maybe can we use a custom helper? Here we're doing .triggers_notifications() which iterates over all the rules, then .triggers_remote_notification() which iterates again. We could iterate once, and figure out on the go if it would trigger a remote or non-remote notification, instead?

[Johennes]

Oh, you're right about cfg_if. I have eliminated it with cd21783.

As for the second comment, it's actually not iterating over the rules but only over the actions on each rule. That array should normally have at most two items. So I think doing that twice is ok-ish?

[Johennes]

For the tests, I'd like to integrate something into matrix-sdk-ui/tests/integration/notification_client.rs but I'm struggling a bit to see how to inject custom push rules in the client. It looks like all the current tests just run with the default push rules?

[bnjbvr]

Sorry, noticed a thing that makes it not ideal to mix the bool within the field. I should've noticed the first time 😔 So let's get back to the new variant instead (with a suggested new name). And yeah let's add some notification client tests for the new notify-in-app mode. Likely we'll need to sync/fetch account data to tweak the default push rules for the user.

[Johennes]

Tests are still missing. I will need to figure out how to extend the existing ones.

[Johennes]

Moving back to draft to re-evaluate alternatives to MSC3768.