Replace all use of the VERIFY macro.

webrtc/p2p/base/dtlstransportchannel.cc

Index: webrtc/p2p/base/dtlstransportchannel.cc
diff --git a/webrtc/p2p/base/dtlstransportchannel.cc b/webrtc/p2p/base/dtlstransportchannel.cc
index 575ec327b982dbe3c61e3f7a6e98e35a4f6e9a00..f46784a98cf4d15e074d9ad343f2e28fabf74a6a 100644
--- a/webrtc/p2p/base/dtlstransportchannel.cc
+++ b/webrtc/p2p/base/dtlstransportchannel.cc
@@ -354,7 +354,9 @@ bool DtlsTransport::SetSrtpCryptoSuites(const std::vector<int>& ciphers) {
     return true;
   }
 
-  if (!VERIFY(dtls_state() == DTLS_TRANSPORT_NEW)) {
+  // TODO(nisse): Bad style of error handling. Should it be a DCHECK or not?

[nisse-webrtc, 2017/02/07 10:48:15]

And what to do about this case?

[kwiberg-webrtc, 2017/02/07 11:45:08]

Dunno. The code should either handle the error, or it should never occur. Just
about the only thing we can be sure of is that our unit tests don't exercise the
error path, since that would have triggered the DCHECK...

Hmm. I just realized that that's a succinct way of explaining why you should
never handle DCHECK failures: the DCHECK works as a guard ensuring that the
error path is never tested...

But back to the immediate problem. I guess one sane way to treat this is to use
CHECK instead of DCHECK, and delete the error handling code, plus leaving a TODO
for yourself to replace the CHECK with a DCHECK in 3-6 months if it never
triggered.

[nisse-webrtc, 2017/02/07 13:52:40]

After looking at the other code in this file, it seems other methods return
error when in an unexpected state, so I'm doing the same here and just delete
the DCHECK.

+  RTC_DCHECK(dtls_state() == DTLS_TRANSPORT_NEW);
+  if (dtls_state() != DTLS_TRANSPORT_NEW) {
     return false;
   }