Implement ALPN in tlslite.

Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
Committed: https://crrev.com/b784c2f5e0e4041f2ccb4949c3a8b4c45a30b16c
Cr-Commit-Position: refs/heads/master@{#410127}

[Bence, 2016-08-01 19:16:10]

The CQ bit was checked by bnc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-01 19:16:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 19:41:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-01 19:41:46]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Bence, 2016-08-02 12:53:02]

The CQ bit was checked by bnc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-02 12:53:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Bence, 2016-08-02 12:53:40]

Description was changed from

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.

BUG=547867
==========

to

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

BUG=547867
==========

[commit-bot: I haz the power, 2016-08-02 13:10:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-02 13:10:57]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Bence, 2016-08-02 20:02:50]

bnc@chromium.org changed reviewers:
+ davidben@chromium.org

[Bence, 2016-08-02 20:02:51]

David: please help me debug flaky
HTTPSSessionTest.DontResumeSessionsForInvalidCertificates.

[davidben, 2016-08-02 20:28:43]

Man, I'd forgotten how bad this stack was... poking about now, but one quick
comment: you might find it easier if you added the alpnProtos config to
HandshakeSettings. All the parameters there were probably a mistake.

[Bence, 2016-08-03 14:20:13]

The CQ bit was checked by bnc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-03 14:20:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-03 15:14:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-03 15:14:35]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Bence, 2016-08-03 15:27:26]

Description was changed from

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

BUG=547867
==========

to

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
==========

[Bence, 2016-08-03 15:27:50]

Description was changed from

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
==========

to

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
==========

[Bence, 2016-08-03 15:28:51]

David, PTAL.

On 2016/08/02 20:28:43, davidben wrote:
> Man, I'd forgotten how bad this stack was... poking about now, but one quick
> comment: you might find it easier if you added the alpnProtos config to
> HandshakeSettings. All the parameters there were probably a mistake.

If it's okay with you, I'm actually fine with plumbing ALPN along the existing
plumbing for NPN, this makes things simpler.

[davidben, 2016-08-03 23:34:22]

(Did you manage to sort out the test flake. I wasn't sure. Sorry I didn't get
around to poking at it.)

https://codereview.chromium.org/2205433002/diff/100001/net/socket/ssl_client_...
File net/socket/ssl_client_socket_unittest.cc (right):

https://codereview.chromium.org/2205433002/diff/100001/net/socket/ssl_client_...
net/socket/ssl_client_socket_unittest.cc:3124: // Server preference SHOULD win
in ALPN.
SHOULD -> should

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/messages.py (right):

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:365: if (structLength + 2 != extLength):
Nit: No parens in Python

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:368: if (alpn_protos.len() != 1):
Ditto.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (right):

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:340: alpnProtos=None,
nextProtos=None, reqTack=True,
Please do move this to the settings object. You won't have to pass it down
everywhere and it will be much simpler.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:558: #Ignore NPN if server response
has ALPN.
This isn't right. If the ServerHello contains both ALPN and NPN, you don't
ignore NPN. That won't work right. You have to hard-fail the connection. See
_clientGetServerHello comment.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:735: yield result
Add a check that ALPN + NPN in a ServerHello is illegal.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:1576: CertificateType.x509, None,
None, None)
ALPN also should happen on session resumption.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:1891: nextProtos, doingChannelID,
useExtendedMasterSecret):
(ALPN doesn't interact interestingly with the Finished message and need not be
passed down here.)

[Bence, 2016-08-04 16:41:39]

The CQ bit was checked by bnc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-04 16:41:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 18:29:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-04 18:29:14]

Dry run: This issue passed the CQ dry run.

[Bence, 2016-08-04 18:41:45]

David: PTAL.

On 2016/08/03 23:34:22, davidben wrote:
> Did you manage to sort out the test flake?

Yes, I did.  Adding ALPN to
HTTPSSessionTest.DontResumeSessionsForInvalidCertificates kicks in TLS False
Start which does not play nicely with session resumption.  There's no easy way
either to disable TLS False Start or to prevent the client from sending ALPN in
HTTPSSessionTest.DontResumeSessionsForInvalidCertificates, so I found the
easiest solution to not Alert in tlslite if there is no ALPN overlap (thus no
need to configure server ALPN in said test).  This was Patch Set 5.

For SSLClientSocketTest.SessionResumptionALPN, I can just disable TLS False
Start in SSLConfig.

I can hardly wait to rip out unused NPN code from SSLClientSocket* once this CL
lands.

https://codereview.chromium.org/2205433002/diff/100001/net/socket/ssl_client_...
File net/socket/ssl_client_socket_unittest.cc (right):

https://codereview.chromium.org/2205433002/diff/100001/net/socket/ssl_client_...
net/socket/ssl_client_socket_unittest.cc:3124: // Server preference SHOULD win
in ALPN.
On 2016/08/03 23:34:22, davidben wrote:
> SHOULD -> should

Done.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/messages.py (right):

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:365: if (structLength + 2 != extLength):
On 2016/08/03 23:34:22, davidben wrote:
> Nit: No parens in Python

Done.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:368: if (alpn_protos.len() != 1):
On 2016/08/03 23:34:22, davidben wrote:
> Ditto.

Done.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (right):

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:340: alpnProtos=None,
nextProtos=None, reqTack=True,
On 2016/08/03 23:34:22, davidben wrote:
> Please do move this to the settings object. You won't have to pass it down
> everywhere and it will be much simpler.

Done.  Also moved nextProtos so that they are together.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:558: #Ignore NPN if server response
has ALPN.
On 2016/08/03 23:34:22, davidben wrote:
> This isn't right. If the ServerHello contains both ALPN and NPN, you don't
> ignore NPN. That won't work right. You have to hard-fail the connection. See
> _clientGetServerHello comment.

Done.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:735: yield result
On 2016/08/03 23:34:22, davidben wrote:
> Add a check that ALPN + NPN in a ServerHello is illegal.

Done.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:1576: CertificateType.x509, None,
None, None)
On 2016/08/03 23:34:22, davidben wrote:
> ALPN also should happen on session resumption.

Done.

https://codereview.chromium.org/2205433002/diff/100001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:1891: nextProtos, doingChannelID,
useExtendedMasterSecret):
On 2016/08/03 23:34:22, davidben wrote:
> (ALPN doesn't interact interestingly with the Finished message and need not be
> passed down here.)

Done.

[davidben, 2016-08-04 22:29:26]

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/messages.py (right):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:102: def parse_next_protos(self, b):
Having this as a method of the HandshakeMsg base class doesn't make a whole lot
of sense. Perhaps just some free functions somewhere? It doesn't actually use
self.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:199: if (structLength + 2 != extLength):
Nit: no parens in Python

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:304: class
InvalidAlpnResponse(Exception):
Nit: Going by TLSConnection, this project seems to prefer InvalidALPNResponse

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/session.py (right):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/session.py:57: self.alpn_proto_selected = None
ALPN protocols are not remembered across session resumption. They're negotiated
independently on each connection.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (left):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:547: # (string or None)
Unintentional lost comment?

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (right):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:542: nextProto =
self._clientSelectNextProto(nextProtos, serverHello)
This variable isn't even defined anymore. I suspect this is only working because
we never run the tlslite client bits.

(I'd probably have just left the nextProtos stuff alone. Not really worth
carrying a diff on that.)

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:1322: settings.nextProtos = None
This function probably should not mutate the settings object? That seems a
little weird.

[Bence, 2016-08-05 13:27:55]

The CQ bit was checked by bnc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-05 13:28:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Bence, 2016-08-05 14:27:55]

PTAL.  Thank you.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/messages.py (right):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:102: def parse_next_protos(self, b):
On 2016/08/04 22:29:26, davidben wrote:
> Having this as a method of the HandshakeMsg base class doesn't make a whole
lot
> of sense. Perhaps just some free functions somewhere? It doesn't actually use
> self.

Done.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:199: if (structLength + 2 != extLength):
On 2016/08/04 22:29:26, davidben wrote:
> Nit: no parens in Python

Done.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/messages.py:304: class
InvalidAlpnResponse(Exception):
On 2016/08/04 22:29:26, davidben wrote:
> Nit: Going by TLSConnection, this project seems to prefer InvalidALPNResponse

Done.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/session.py (right):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/session.py:57: self.alpn_proto_selected = None
On 2016/08/04 22:29:26, davidben wrote:
> ALPN protocols are not remembered across session resumption. They're
negotiated
> independently on each connection.

Done.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (left):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:547: # (string or None)
On 2016/08/04 22:29:26, davidben wrote:
> Unintentional lost comment?

Oops.  Done.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (right):

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:542: nextProto =
self._clientSelectNextProto(nextProtos, serverHello)
On 2016/08/04 22:29:26, davidben wrote:
> This variable isn't even defined anymore. I suspect this is only working
because
> we never run the tlslite client bits.
> 
> (I'd probably have just left the nextProtos stuff alone. Not really worth
> carrying a diff on that.)

(1) Done.
(2) I have to admit that I have not run the tlslite tests locally.  The tests of
course fail on this line.
(3) I was contemplating not touching nextProtos, but in the end I decided to
move it together with alpnProtos to make is easier for the next poor developer
who needs to grok this code.

https://codereview.chromium.org/2205433002/diff/140001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:1322: settings.nextProtos = None
On 2016/08/04 22:29:26, davidben wrote:
> This function probably should not mutate the settings object? That seems a
> little weird.

Done.

[davidben, 2016-08-05 15:59:34]

lgtm with one comment.

https://codereview.chromium.org/2205433002/diff/220001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (left):

https://codereview.chromium.org/2205433002/diff/220001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:340: nextProtos=None, reqTack=True,
serverName="",
It looks like this nextProtos is actually in upstream. I think I would prefer we
leave it as-is just so we can keep the diff smaller. Not that it's likely we'll
merge with upstream ever again.

[Bence, 2016-08-05 17:57:13]

The CQ bit was checked by bnc@chromium.org

[Bence, 2016-08-05 17:57:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
davidben@chromium.org
Link to the patchset: https://codereview.chromium.org/2205433002/#ps240001
(title: "Moving nextProtos back to where it was.")

[commit-bot: I haz the power, 2016-08-05 17:57:35]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Bence, 2016-08-05 17:57:45]

Thank you.

https://codereview.chromium.org/2205433002/diff/220001/third_party/tlslite/tl...
File third_party/tlslite/tlslite/tlsconnection.py (left):

https://codereview.chromium.org/2205433002/diff/220001/third_party/tlslite/tl...
third_party/tlslite/tlslite/tlsconnection.py:340: nextProtos=None, reqTack=True,
serverName="",
On 2016/08/05 15:59:34, davidben wrote:
> It looks like this nextProtos is actually in upstream. I think I would prefer
we
> leave it as-is just so we can keep the diff smaller. Not that it's likely
we'll
> merge with upstream ever again.

Done.

[commit-bot: I haz the power, 2016-08-05 19:09:55]

Description was changed from

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
==========

to

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
==========

[commit-bot: I haz the power, 2016-08-05 19:09:56]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-08-05 19:11:52]

Description was changed from

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867
==========

to

==========
Implement ALPN in tlslite.

* Update SSLClientSocketFalseStartTests to use ALPN.
* Add SSLClientSocketTest test cases for ALPN.
* Implement ALPN in tlslite.
* Plumb ALPN through SpawnedTestServer.
* Configure server ALPN for URLRequest tests so that
  connection does not fail.

Note that the ALPN implementation introduced by this CL does not conform to the
RFC: if there is no overlap between client and server supported protocols, ALPN
is ignored, whereas the specification prescribes an Alert to be sent.  This by
the way matches BoringSSL's implementation.  Also, it is simpler for tests: most
net_unittests against tlslite do not worry about the actual protocol negotiated,
and this way there is no need to configure the server ALPN list.

BUG=547867

Committed: https://crrev.com/b784c2f5e0e4041f2ccb4949c3a8b4c45a30b16c
Cr-Commit-Position: refs/heads/master@{#410127}
==========

[commit-bot: I haz the power, 2016-08-05 19:11:53]

Patchset 13 (id:??) landed as
https://crrev.com/b784c2f5e0e4041f2ccb4949c3a8b4c45a30b16c
Cr-Commit-Position: refs/heads/master@{#410127}