LG-11430: hide ft unlock unless has public credential support

[mdiarra3]

🎫 Ticket

LG-11430: hide ft unlock if not available

🛠 Summary of changes

This puts back the check for ensuring that platform authenticator is available for the device not just that the browser supports it.

📜 Testing Plan

• Users with properly set up devices are still able to view F/T Unlock at account creation
• users without properly set up devices will not be able to view f/t unlock at account creation

[aduth]

Can you add the pull request template to the original comment?

[aduth]

It's a little tricky to test, but I was able to mostly fake it and verify the input is hidden. LGTM! 👍

[aduth]

For the RSpec tests, we might need to find a way to fake support in JavaScript-enabled contexts, similar to what we're doing here:

identity-idp/spec/support/features/webauthn_helper.rb

Lines 86 to 98 in 2afb1de

	page.evaluate_script(<<~JS)
	base64ToArrayBuffer = (base64) => Uint8Array.from(atob(base64), (c) => c.charCodeAt(0)).buffer;
	JS
	page.evaluate_script(<<~JS)
	navigator.credentials.get = () => Promise.resolve({
	rawId: base64ToArrayBuffer(#{credential_id.to_json}),
	response: {
	authenticatorData: base64ToArrayBuffer(#{authenticator_data.to_json}),
	clientDataJSON: base64ToArrayBuffer(#{verification_client_data_json.to_json}),
	signature: base64ToArrayBuffer(#{signature.to_json}),
	},
	});
	JS

e.g. Maybe something like?

page.evaluate_script(<<~JS)
  window.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable = () => Promise.resolve(true);
JS

[aduth]

Oof, I'd forgot about needing this. I think it makes sense, though I'd be a little concerned about future maintainability if the connected callback has some side effects that might be doubled-up by calling it explicitly like this.

In the past I'd wondered if we could use the Chrome DevTools protocol support for WebAuthn to add a "virtual" authenticator, but it was experimental and I had a hard time getting it working. Might be something to reconsider in the future.