Be more tolerant of user input for auth codes

[dd32]

Currently the TOTP (and backup codes / email codes, but that's less relevant) user input is tollerant of leading/trailing spaces, but doesn't accept TOTP codes that are entered how most apps display them: 123 456.

This PR does several things:

• Adds a placeholder value to the fields, so as to convey the format expected.
• Makes it tolerant of whitespace in the middle of the number (123 456)
• Removes sanitize_text_field() and uses REQUEST & wp_unslash() consistently between the providers. sanitize_text_field() has been removed as it strips characters from the provided code.. which shouldn't really be needed.. as invalid input is an invalid code.
• Adds a unit test to cover the invalid characters / whitespace changes.

Examples using TOTP, the others are similar just with 78 affixed.

Before	After	Invalid Input

After Feedback from Ian:

Before	After
	(Spaces in input highlighted)
	Entering a character other than numbers and spaces ([0-9 ]*) are stripped and do not "enter" into the field, avoiding the "does not match expected format" error.

Notably, it doesn't handle invalid input (non-numeric/space) well. But at least now the "Match the format requested" is more obvious based on the placeholder value presented.

[iandunn]

LGTM 👍🏻

[iandunn]

Suggested change

	$placeholder = sprintf( __( 'eg. %s', 'two-factor' ), '123456' );
	$placeholder = sprintf( __( 'eg. %s', 'two-factor' ), '123 456' );

[dd32]

I've taken a slightly different approach, which I'd like your review on @iandunn.

Instead of treating it like a string number, or groups of two digits, I've instead increased the width between all the characters, which both makes it easier to read, and due to the increased space, "feels like" (to me) that there's less of a requirement for spaces on the input (as it's auto-spaced).

Adding a space between the chunks like this is still possible, and ends up like this:

Current	with extra space	user input
		(no user-input spaces)

[iandunn]

🤔 , I like this better than e.g., 123 456. I lean towards 123 456 being best, though. IMO blocks of numbers like in auth codes have two problems:

1. they're hard to read because the numbers all run together
2. they're hard to remember because the sequence is too long

Adding extra (uniform) space between each letter solves 1, but not 2. Grouping the numbers into small blocks like 123 456 solves both problems IMO.

I don't feel strongly, though. I think 1 2 3 4 5 6 is an improvement on the current situation 👍🏻

[jeffpaul]

FWIW, GitHub itself uses XXXXXX as the placeholder text, but I concur with you here that 1 2 3 4 5 6 seems "better".

[dd32]

GitHub itself uses XXXXXX as the placeholder text

I've always been partial to the Stripe UI (and similar ones) that use dedicated boxes. Those that use this format however are less flexible of singular input boxes that just "accept a two factor challenge response" (ie. TOTP/Backup/Email/SMS/etc code)