Fallback to the default push gateway on error

[p1gp1g]

Content

Based on #5741.

Fallback to the default gateway if the discovery request returns an error and no gateway was recorded for the push server yet.

Motivation and context

We have the issue #5723 because the gateway resolver uses the custom gateway by default, when the request fails and the push server doesn't have any gateway yet. This exact issue is fixed with #5741 because 406 is included in valid responses showing no gateway is available. But we wouldn't have that issue if the fallback was to the default gateway.

I have split the 2 patchs in 2 PR, because I may not be aware of a need that let you choose to fallback to the custom gateway instead of the default, and I don't want to block the other patch.

Tests

• Install Sunup
• Enable UnifiedPush and selection Sunup
• Go to notification troubleshooting list
• Observe the nonexistent gateway being used

Tested devices

• Physical
• Emulator
• OS version(s):

Checklist

• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly define what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.71%. Comparing base (e22c976) to head (dfc8b70).
⚠️ Report is 180 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5742      +/-   ##
===========================================
- Coverage    79.71%   79.71%   -0.01%     
===========================================
  Files         2422     2422              
  Lines        65059    65067       +8     
  Branches      8303     8304       +1     
===========================================
+ Hits         51861    51866       +5     
- Misses       10225    10229       +4     
+ Partials      2973     2972       -1     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bmarty]

Thanks, just a question, see the other comment

[bmarty]

Maybe instead of patching the code here, gatewayResult.gateway could contains the value of defaultPushGatewayHttpUrlProvider.provide()?

I am confused since we decided to provide the customUrl to the Error class in the past. Have we changed our mind?

[p1gp1g]

It used to return the default gateway: 2037065#diff-54db23386c84f03ffe631a6af4461af92d353f352f1b23025f14875d1175a0b4R49

[jmartinesp]

I think this changed in #3388, there is even a comment from @p1gp1g in it 😅 .

IMO, using the default/fallback gateway when the custom one isn't present or working makes sense. Although maybe we should display some toast/notification in that case so the user is aware of that?

[p1gp1g]

I don't know if the toast is a good idea, some users are already confused that the gateway isn't their push server, and it may add more confusion

There are some action regarding the webpush MSC, I hope this gateway will be an old story soon :)