fix(call): recover subscriber connections stuck before ICE failure

[tareko]

With the high performance backend a subscriber connection that stays in "disconnected" is not acted upon, as only "failed" connections request a new offer. However, some browsers may never report the connection as "failed" (and ICE has no timeout at all while in "new" state, with "checking" also able to get stuck), so the participant tile stays in "connecting" state and no audio is heard until the call is rejoined.

Extract the existing "request offer and retry every 10 seconds until received" logic into a helper and reuse it from two new watchdogs for MCU subscriber peers:

• a connection still "disconnected" 10 seconds after entering the state requests a new offer,
• a connection still in "new" or "checking" state 30 seconds after the peer was created requests a new offer (re-armed for each replacement peer, so recovery keeps retrying until it succeeds).

The retry interval is cleared when the new offer arrives, and the state guards make the timers no-ops once the connection leaves the stuck state or the peer is ended. Non-MCU connections and the own publishing peer are intentionally left unchanged.

Assisted-by: OpenCode:moonshotai/kimi-k3

☑️ Resolves

• Fixes Try to establish the connection again also in "phantom" connection failures #5931

AI

• The content of this PR was partly or fully generated using AI

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[tareko]

Quick ping that I've been using this patch in production since I posted it and it has been working very well so far.

[Antreesy]

Thanks for confirmation! Sorry it has slipped our attention... We'll try to get this reviewed soon

cc @danxuliu for a better expertise

[danxuliu]

Sorry for the delay and thanks a lot for your contribution!

I also noticed the problem with the lack of reconnections when the peer was stuck in the new state and I wanted to take a look to it, but never found the time, so thanks for the fix :-) Maybe some further adjustments will be done in the future once I dive into it, but for now the proposed fix looks good.

However, regarding the browsers getting stuck in disconnected, it is a known behaviour of Chromium based browsers that should be being handled already 🤔

Did you notice a different browser getting stuck in disconnected? If it was with a Chromium based browser, would you have reproduction steps to check why the existing guard is not working as expected?

As far as I remember some browsers may take quite some time (up to 30 seconds) to change from disconnected to failed, could it be the case here?

Independently of all that, could you split the commit into a refactoring commit that extracts requestOfferFromMcuAndRetryUntilReceived and another one that provides the actual fix (which might need further adjustments based on the above, but we will see)? Thanks!