Send W3C capabilities in the new session request.

[juangj]

If the Selenium standalone server only finds legacy capabilities in the request,
then it will assume that the client doesn't speak W3C, and will return a legacy
response. Sending a request that includes the W3C keys induces it to send a W3C
response.

• By placing an X in the preceding checkbox, I verify that I have signed the Contributor License Agreement

[juangj]

This probably also applies to Grid, but I'm really not that familiar with Grid so I'm not positive.

Other language bindings do fancier things like filtering non-W3C capability names out of the W3C capabilities blob (here it is in Python). Not sure how necessary you feel that is.

Also kinda undecided how to treat required capabilities, but those should go away at some point anyway, so maybe you were already planning an API change to eliminate them.

[jleyba]

Do the tests pass with this change? Last time I tried there were a lot of failures still.

[jleyba]

Actually, it looks like the entire normalizeProxyConfiguration function isn't needed anymore

[juangj]

npm test passed (or, well, it didn't fail any more than it already did on my machine). And this seemed to work for many tests, but it doesn't work for tests that set non-W3C capabilities.

I do have some code (probably living in the wrong file right now) that will filter non-W3C capability names like some of the other language bindings do. But if you're planning to completely ditch legacy protocol support anyway, then maybe there's no need for any of this -- once all the capability names are changed, you could just switch completely to W3C capabilities instead of sending this hybrid.

(I'm going to backport some version of this to our internal 3.6.0 branch in order to continue to support Chrome users, though.)

[juangj]

I added that commit that drops invalid capabilities, if you're curious.

The normalizeProxyConfiguration thing should probably just go in a separate commit.