Add labs flag to automatically rageshake on decryption errors

[duxovni]

Also sends a to-device message to the sender, prompting them to auto-rageshake too if they have this lab enabled as well.

Fixes element-hq/element-web#19430.

This should interoperate with element-hq/element-android#4325, although we don't currently provide the recipient's rageshake URL when asking the sender to rageshake, and we don't use any of the information provided in the to-device message yet.

---

This PR currently has no changelog labels, so will not be included in changelogs.

A reviewer can add one of: T-Deprecation, T-Enhancement, T-Defect, T-Task to indicate what type of change this is, or add Type: [enhancement/defect/task] to the description and I'll add them for you.

Preview: https://61e03a7db9323f64587c6f37--matrix-react-sdk.netlify.app
⚠️ Do you trust the author of this PR? Maybe this build will steal your keys or give you malware. Exercise caution. Use test accounts.

[SimonBrandner]

Just a question about styling, otherwise I am looking forward to seeing UISIs disappear! Thanks!

[duxovni]

Good catch, thank you!

[duxovni]

Thanks for the feedback; I haven't worked with AsyncStoreWithClient before, but I think I'm using it correctly based on the other examples in the codebase?

One other thing to note: In my local tests, when the recipient rageshakes and then asks the sender to rageshake as well, the sender's rageshake can fail with a 500, because the rageshake server assigns URIs based on timestamps with 1-second precision and the two rageshakes happen within the same second. I'm not sure if there's some option I should be setting in my local rageshake server instance to avoid these collisions, or if this is just a bug in the rageshake server, but it doesn't seem like it's within the scope of this PR in any case.

[t3chguy]

One other thing to note: In my local tests, when the recipient rageshakes and then asks the sender to rageshake as well, the sender's rageshake can fail with a 500, because the rageshake server assigns URIs based on timestamps with 1-second precision and the two rageshakes happen within the same second. I'm not sure if there's some option I should be setting in my local rageshake server instance to avoid these collisions, or if this is just a bug in the rageshake server, but it doesn't seem like it's within the scope of this PR in any case.

This seems like a major thing, yes outside of the scope of this PR but would potentially block this PR until fixed.

[duxovni]

Remaining todos after discussion with @BillCarsonFr:

• Include link to matching issue in title so github will make it an actual link
• Include information about the specific message that triggered the rageshake
• Change matching_issue to recipient_rageshake to match Android

[t3chguy]

Looks sane to me! Thanks

[BillCarsonFr]

LGTM