Avoid establishing a shared secret for CTAP 2.0 authenticators when hmac-secret is not requested

[jschanck]

In Bug 1936283 we have an example of an authenticator that returns a COSEKey with the wrong algorithm field in its GetKeyAgreement response. The authenticator has a built-in fingerprint reader, and does not support the getPinUvAuthTokenUsingUvWithPermissions function, so we should not need to establish a shared secret, however we establish one opportunistically in case we need to use the hmac-secret extension:

authenticator-rs/src/ctap2/mod.rs

Lines 293 to 295 in 1959330

	if info.supports_hmac_secret() {
	let _shared_secret = dev.establish_shared_secret(alive)?;
	}

We should avoid establishing a shared secret for CTAP 2.0 authenticators when hmac-secret is not explicitly requested.