After enabling CTAP Chrome will crash when connecting to a BLE key fails.

Reproduction on Linux:

1. Start a recent build with --enable-features="WebAuthenticationBle"
2. Open https://webauthn.io and register a credential for a BLE key.
3. Click back button, and click login.

What is the expected result?
Ideally login succeeds after pressing the BLE key.

What happens instead of that?
Chrome crashes:

[247224:247224:0808/160813.378190:ERROR:fido_ble_connection.cc(317)] CreateGattConnection() failed: ERROR_FAILED
[247224:247224:0808/160813.379303:FATAL:fido_ble_frames.cc(59)] Check failed: max_fragment_size >= 3u (0 vs. 3)
#0 0x7fac52a7f1fc base::debug::StackTrace::StackTrace()
#1 0x7fac529a449b logging::LogMessage::~LogMessage()
#2 0x7fac4c73fbe6 device::FidoBleFrame::ToFragments()
#3 0x7fac4c741ed0 device::FidoBleTransaction::WriteRequestFrame()
#4 0x7fac4c73c438 device::FidoBleDevice::SendRequestFrame()
#5 0x7fac4c73c093 device::FidoBleDevice::Transition()
#6 0x7fac4c73b810 device::FidoBleDevice::AddToPendingFrames()
#7 0x7fac4c73bc99 device::FidoBleDevice::DeviceTransact()
#8 0x7fac4c75fb8f device::DeviceOperation<>::DispatchDeviceRequest()
#9 0x7fac4c760e63 device::U2fSignOperation::Start()
#10 0x7fac4c756280 device::GetAssertionTask::U2fSign()
#11 0x7fac4c755e25 device::GetAssertionTask::StartTask()
#12 0x7fac4c73e9e4 _ZN4base8internal7InvokerINS0_9BindStateIMN6device20FidoBleDiscoveryBaseEFvvEJNS_7WeakPtrINS3_16FidoBleDiscoveryEEEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#13 0x7fac5298330d base::debug::TaskAnnotator::RunTask()

The root cause seems to be the following:
- A connection failure will set the device state to kDeviceError and all pending callbacks are run with a base::nullopt.
- This will invoke FidoDevice::OnDeviceInfoReceived, which treats the nullopt simply as an error to understand a CTAP GetInfo command and sets the device state to kReady.
- This will also invoke GetAssertionTask::U2fSign(), which attempts to send another command to the device.
- As preparation, the command will be split into frames and fragments.
- FidoBleFrame::ToFragments() will be invoked with the control point length, but given that this was never read its value is 0.
- This triggers the DCHECK, as 0 is smaller than 3.

Enabling CTAP by default seems to be the issue here, as previously FidoDevice::DiscoverSupportedProtocolAndDeviceInfo didn't attempt to communicate with the device.

As a fix we likely should distinguish between connection errors and CTAP errors. A connection error (such as failing to create a gatt connection, failing to read the control point length or failing to subscribe to notifications) should be treated as a fatal error, from which we likely can't recover. A CTAP error however is expected in some cases (e.g. as a response to a GetInfo command), and should be treated differently. Assigning to Jun, as he is likely the most knowledgeable on this part now.