Update identity reset UI (Make consistent with EX)

[andybalaam]

Fixes #29227

This adds IdentityResetDialog, which wraps IdentityResetBody in a dialog, and launches it from SetupEncryptionBody, instead of doing the reset directly there. In the new flow, only the user's cryptographic identity is reset -- recovery is no longer set up at the same time.

This is mostly work by @uhoreg , rebased and refactored a bit here.

I recommend reviewing commit-by-commit.

[richvdh]

Slightly struggling to understand the scope of the changes here.

Make identity reset consistent with EX

Before I try and page in the code changes again, could we rephrase this in a way that summarises what's actually changing in EW as part of this change? A few screenshots might not go amiss, either.

Fixes #29227

The linked issue isn't terribly helpful at getting an overview of what actually needs to change: it links to a load of designs but I'm unclear what is already done and what this PR is aiming to change. But in particular: #29227 talks about changing something in the OIDC flow, which doesn't seem to be done here? Is that because it's already done?

I recommend reviewing commit-by-commit.

I assume this is no longer the recommended approach?

[uhoreg]

Slightly struggling to understand the scope of the changes here.

Make identity reset consistent with EX

Before I try and page in the code changes again, could we rephrase this in a way that summarises what's actually changing in EW as part of this change? A few screenshots might not go amiss, either.

Added a screenshot, and updated the title. It is "just" a UI update, with the annoying part being that in order to get the desired UI, I had to make it pop up a new modal, rather than to do it all in SetupEncryptionBody.

Fixes #29227

The linked issue isn't terribly helpful at getting an overview of what actually needs to change: it links to a load of designs but I'm unclear what is already done and what this PR is aiming to change. But in particular: #29227 talks about changing something in the OIDC flow, which doesn't seem to be done here? Is that because it's already done?

Looks like Andy and I both missed the OIDC part. But I've split it off into #29809 since it's a separate component and is non-trivial.

I recommend reviewing commit-by-commit.

I assume this is no longer the recommended approach?

Yes, by now it has accumulated enough commits that that approach may not be the best.

[richvdh]

This could maybe do with being onResetCompleted or onIdentityReset or something, just to help highlight it's the completion of the identity reset process, rather than the component being reset or something.

Not a strong opinion though.

[richvdh]

I know this has been discussed previously, but it does seem a bit weird for this to be a MouseEventHandler and at some point it would be nice to just make it a () => void like onCancelClick. But, it's not a new change in this PR and doesn't need to hold this PR up any more, so maybe another time.

[uhoreg]

I agree, but, Friday afternoon, before I'm off for two weeks, I'm making minimal changes. ;) (same goes for #29701 (comment))

[richvdh]

In case it's not obvious, the main point in the above review is #29701 (comment) (basically: can we get rid of Phase.ConfirmReset altogether). The rest is mostly nit-picking.

[richvdh]

notwithstanding my comments about getting rid of returnAfterReset, there is an easier way to do this.

1. Have ResetIdentityDialog's onFinished prop take an optional boolean success argument. Where we run that callback from onResetWrapper, set the argument to true.
2. Use the finished promise returned by createDialog to figure out if we successfully did the reset:

      const handle = Modal.createDialog(
          ResetIdentityDialog,
          /* props= */ {
              variant: "confirm",
          },
      );
      handle.finished.then(([success]) => {
          if (success) {
              // The user completed the reset process - close this dialog
              this.props.onFinished();
              store.done();
          } else {
              // The user clicked away - go back a step
              store.returnAfterReset();
          }
      }); 

[richvdh]

This looks basically fine now but I think there's a bit of cruft left that we can clean up.

[richvdh]

A few more suggestions which might help make this clearer. The Modal API is unintuitive and very poorly documented 😢