Revert of Allow the DTLS fingerprint verification to occur after the handshake.

Revert of Allow the DTLS fingerprint verification to occur after the handshake. (patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )

Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.

Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
>    Note that when the offer/answer model is being used, it is possible
>    for a media connection to outrace the answer back to the offerer.
>    Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
>    role, it MUST (as specified in RFC 4145 [2]) begin listening for an
>    incoming connection as soon as it sends its offer.  However, it MUST
>    NOT assume that the data transmitted over the TLS connection is valid
>    until it has received a matching fingerprint in an SDP answer.  If
>    the fingerprint, once it arrives, does not match the client's
>    certificate, the server endpoint MUST terminate the media connection
>    with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}

TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Committed: https://crrev.com/81f6f4fc56d4bb4c3f43c30a5fed401d39fddcb4
Cr-Commit-Position: refs/heads/master@{#14298}

[Taylor Brandstetter, 2016-09-20 00:20:34]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-09-20 00:20:35]

Created Revert of Allow the DTLS fingerprint verification to occur after the
handshake.

[commit-bot: I haz the power, 2016-09-20 00:20:45]

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

[commit-bot: I haz the power, 2016-09-20 00:20:55]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-20 00:21:05]

Description was changed from

==========
Revert of Allow the DTLS fingerprint verification to occur after the handshake.
(patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )

Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface
(returning error code instead of bool) in a backwards compatible way.

Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
> 
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
> 
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
> 
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
> 
>    Note that when the offer/answer model is being used, it is possible
>    for a media connection to outrace the answer back to the offerer.
>    Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
>    role, it MUST (as specified in RFC 4145 [2]) begin listening for an
>    incoming connection as soon as it sends its offer.  However, it MUST
>    NOT assume that the data transmitted over the TLS connection is valid
>    until it has received a matching fingerprint in an SDP answer.  If
>    the fingerprint, once it arrives, does not match the client's
>    certificate, the server endpoint MUST terminate the media connection
>    with a bad_certificate error, as stated in the previous paragraph.
> 
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
> 
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}

TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
==========

to

==========
Revert of Allow the DTLS fingerprint verification to occur after the handshake.
(patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )

Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface
(returning error code instead of bool) in a backwards compatible way.

Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
>    Note that when the offer/answer model is being used, it is possible
>    for a media connection to outrace the answer back to the offerer.
>    Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
>    role, it MUST (as specified in RFC 4145 [2]) begin listening for an
>    incoming connection as soon as it sends its offer.  However, it MUST
>    NOT assume that the data transmitted over the TLS connection is valid
>    until it has received a matching fingerprint in an SDP answer.  If
>    the fingerprint, once it arrives, does not match the client's
>    certificate, the server endpoint MUST terminate the media connection
>    with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}

TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387

Committed: https://crrev.com/81f6f4fc56d4bb4c3f43c30a5fed401d39fddcb4
Cr-Commit-Position: refs/heads/master@{#14298}
==========

[commit-bot: I haz the power, 2016-09-20 00:21:05]

Patchset 1 (id:??) landed as
https://crrev.com/81f6f4fc56d4bb4c3f43c30a5fed401d39fddcb4
Cr-Commit-Position: refs/heads/master@{#14298}