chore: Add a way to remove an invalid token if sendFCM returns 404

[Gustrb]

Proposed changes (including videos or screenshots)

The old library (node-gcm) we used to send messages via the legacy push had some utilities to help us out implementing the specification described here on how to handle error codes, and we used to functions, _removeToken and _replaceToken to minimize the number of unnecessary errors we would propagate over.
Now, we had to implement the utility to send messages manually, in #32208 now, we implemented most of the error handling utilities in the function called fetchWithRetry, but there was a big one missing, the 404 case.
From the spec:

UNREGISTERED (HTTP error code = 404) App instance was unregistered from FCM. This usually means that the token used is no longer valid and a new one must be used.

This error can be caused by missing registration tokens, or unregistered tokens.
Missing Registration: If the message's target is a token value, check that the request contains a registration token.
Not registered: An existing registration token may cease to be valid in a number of scenarios, including:

• If the client app unregisters with FCM.
• If the client app is automatically unregistered, which can happen if the user uninstalls the application. For example, on iOS, if the APNs Feedback Service reported the APNs token as invalid.
• If the registration token expires (for example, Google might decide to refresh registration tokens, or the APNs token has expired for iOS devices).
• If the client app is updated but the new version is not configured to receive messages.

For all these cases, remove this registration token from the app server and stop using it to send messages.

OBS: not adding replaceToken because the new Firebase API does not return the new device token ever, so it is better to just remove it, and let it be recreated when a new push gets sent.

Issue(s)

CONN-205

Steps to test or reproduce

You can just follow: #32208

Further comments

[dionisio-bot]

Looks like this PR is not ready to merge, because of the following issues:

• This PR is missing the 'stat: QA assured' label
• This PR is targeting the wrong base branch. It should target 6.10.0, but it targets 6.9.0

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

[changeset-bot]

⚠️ No Changeset found

Latest commit: 93b79cf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.82%. Comparing base (4b8c215) to head (93b79cf).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #32440      +/-   ##
===========================================
+ Coverage    55.81%   55.82%   +0.01%     
===========================================
  Files         2413     2413              
  Lines        53160    53160              
  Branches     10925    10925              
===========================================
+ Hits         29669    29679      +10     
+ Misses       20871    20863       -8     
+ Partials      2620     2618       -2     

Flag	Coverage Δ
e2e	55.10% <ø> (+0.03%)	⬆️
e2e-api	41.11% <ø> (-0.06%)	⬇️
unit	72.92% <ø> (+0.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[geekgonecrazy]

I guess this means this fix can't be backported if we are taking these out?

[Gustrb]

I think we could, not sure if it is worth it though.
Since these parameters are still being passed to the sendFCM I am just not destructuring the _replaceTokens one, since we don't need it here.
I was being dumb in the previous PR, instead of adding this comment I could've just not desctructured them :)