Unknown capabilities cause session creation to fail during `firstMatch` validation

[foolip]

In https://github.com/w3c/webdriver-bidi/pull/24/files#r434807040 I did some testing of "firstMatch" handling. Simplifying it here, I tried POSTing this payload to /session with chromedriver, geckodriver and safaridriver:

{
  "capabilities": {
    "firstMatch": [
      {
        "futureThing": 42
      },
      {}
    ]
  }
}

Tested with curl -d '{"capabilities":{"firstMatch":[{"futureThing": 42},{}]}}' "http://localhost:4444/session".

All 3 drivers fail with "invalid argument" error with these messages:

• chromedriver: "invalid argument: entry 0 of 'firstMatch' is invalid\nfrom invalid argument: unrecognized capability: futureThing"
• geckodriver: "futureThing is not the name of a known capability or extension capability"
• safaridriver: "Unknown capability encountered: 'futureThing' = '42'"

Per spec I think this is not intended, as a "validated capabilities" list is constructed.

I want to check in with those more familiar with the spec before doing anything more:

• If all implementations agree, should the spec just be changed to match them? The spec behavior seems more sensible, but perhaps all implementations agree for a good reason?
• Is the spec not broken here? The "validated capabilities" list is appended to unconditionally, the error case isn't checked.

[jgraham]

So apparently I entirely forgot where the spec ended up on this.

At the moment, if we don't recognise a capability at all we fail validation, and failing validation ends up returning an error from the whole processing capabilites algorithm. So implementations are correct per spec, and a client that wanted to use some non-extension capabilities that may or may not be recognised would have to make multiple attempts at constructing a session.

The bidi stuff seems like an example of where this is bad, but I don't recall all the arguments that led to the current setup. Maybe @shs96c does.