FCM push notification priorities

**Describe the bug**
Firebase cloud messaging has three types of message available (https://firebase.google.com/docs/cloud-messaging/concept-options#delivery-options) collapsible messages and non-collapsible with either normal or high priority.

Element Android doesn't change behaviour based on the priority of a message, and will always trigger a background sync if the event hasn't been seen yet (https://github.com/vector-im/element-android/blob/develop/vector/src/gplay/java/im/vector/app/gplay/push/fcm/VectorFirebaseMessagingService.kt#L162).

Google's documentation suggests "Calling back to the server before the end of the allowed processing time may be risky for users on high latency networks. Instead, include the notification content in the FCM message and display it immediately." and "app standby buckets [...] limit the number of FCM high priority messages you can send to your app that don't result in the user using your app or viewing a notification".

I've not managed to find documentation on the types of message that are sent through FCM, and while I've got a local debug build running on my device I'm afraid I still seem to be building the FDroid variant.

The behaviour I observe is that notifications are frequently either delayed or missing. My hypothesis is that this may be because we're sending messages with an inappropriate type or priority, and that even with the correct priority, we need the system to schedule a worker to sync before we'll retrieve the message and display a notification -- and (https://developer.android.com/topic/performance/power/power-details) even working set applications may delay workers for up to two hours.

The type of notification expected for a message to any given room should be used to determine the type and priority of the push notification generated for it. Generating collapsible notifications for any state change should trigger an eventual sync. We should avoid sending high priority messages for rooms which aren't set to notify for that message type or for events that aren't configured to generate a notification, and in any case should avoid sending a push notification without including the context required to generate a notification before a background sync completes. Ideally we wouldn't need to trigger the sync until either the system has decided to act on a collapsible notification or the user has triggered the notification.

**Expected behavior**
FCM messages trigger background sync as a low-priority collapsible event, and high priority events are limited to avoid depleting app standby buckets. Notification display does not depend on a worker being scheduled.