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