Refactor the various email/phone management UI into a single component (

#12884)

* Refactor the various email/phone management UI into a single component

These were basically the same component copied & pasted 3 times and
tweaked to match the behaviour of each case. This de-dupes them into
one component.

This all could really benefit from playwright tests, but would require
setting up a dummy ID server in the playwright tests. This is all legacy
pre-MAS stuff so its questionable whether its worth the effort.

* Basic test, remove old tests

* Use different text to confirm remove & put headers back

although the two texts are both 'Remove' in practice

* Remove string

This was never triggered anyway with sydent & synapse because they
don't seem to agree on what error to return. In any case, I think it
makes more sense for it to be consistent with the email path, ie. using
a dialog.

* Avoid nested forms

* Snapshots

* More snapshots

* Test the hs side

* Snapshots

* Test IS bind/revoke

* Test remove can be cancelled

* Test unvalidated cases & fix phone error

* Reset state between tests

* Import useState directly

* One more direct React import

res/css/_components.pcss

@@ -37,7 +37,7 @@
 @import "./components/views/messages/shared/_MediaProcessingError.pcss";
 @import "./components/views/pips/_WidgetPip.pcss";
 @import "./components/views/polls/_PollOption.pcss";
-@import "./components/views/settings/_EmailAddressesPhoneNumbers.pcss";
+@import "./components/views/settings/_AddRemoveThreepids.pcss";
 @import "./components/views/settings/devices/_CurrentDeviceSection.pcss";
 @import "./components/views/settings/devices/_DeviceDetailHeading.pcss";
 @import "./components/views/settings/devices/_DeviceDetails.pcss";

res/css/components/views/settings/_EmailAddressesPhoneNumbers.pcss → res/css/components/views/settings/_AddRemoveThreepids.pcss

@@ -21,17 +21,29 @@ limitations under the License.
  * tab sensibly and before I can refactor these components.
  */
 
-.mx_EmailAddressesPhoneNumbers_discovery_existing {
+.mx_AddRemoveThreepids_existing {
     display: flex;
     align-items: center;
 }
 
-.mx_EmailAddressesPhoneNumbers_discovery_existing_address,
-.mx_EmailAddressesPhoneNumbers_discovery_existing_promptText {
+.mx_AddRemoveThreepids_existing_address,
+.mx_AddRemoveThreepids_existing_promptText {
     flex: 1;
     margin-right: 10px;
 }
 
-.mx_EmailAddressesPhoneNumbers_discovery_existing_button {
+.mx_AddRemoveThreepids_existing_button {
     margin-left: 5px;
 }
+
+.mx_EmailAddressesPhoneNumbers_verify {
+    display: flex;
+}
+
+.mx_EmailAddressesPhoneNumbers_existing_button {
+    justify-content: right;
+}
+
+.mx_EmailAddressesPhoneNumbers_verify_instructions {
+    flex: 1;
+}

src/AddThreepid.ts

@@ -271,9 +271,7 @@ export default class AddThreepid {
      * with a "message" property which contains a human-readable message detailing why
      * the request failed.
      */
-    public async haveMsisdnToken(
-        msisdnToken: string,
-    ): Promise<[success?: boolean, result?: IAuthData | Error | null] | undefined> {
+    public async haveMsisdnToken(msisdnToken: string): Promise<[success?: boolean, result?: IAuthData | Error | null]> {
         const authClient = new IdentityAuthClient();
 
         if (this.submitUrl) {
@@ -301,13 +299,14 @@ export default class AddThreepid {
                 id_server: getIdServerDomain(this.matrixClient),
                 id_access_token: await authClient.getAccessToken(),
             });
+            return [true];
         } else {
             try {
                 await this.makeAddThreepidOnlyRequest();
 
                 // The spec has always required this to use UI auth but synapse briefly
                 // implemented it without, so this may just succeed and that's OK.
-                return;
+                return [true];
             } catch (err) {
                 if (!(err instanceof MatrixError) || err.httpStatus !== 401 || !err.data || !err.data.flows) {
                     // doesn't look like an interactive-auth failure