Revert of Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.

Revert of Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface. (patchset #2 id:20001 of https://codereview.webrtc.org/2013523002/ )

Reason for revert:
There are more CreatePeerConnection calls than I anticipated/had found in Chromium, like remoting/protocol/webrtc_transport.cc. Reverting due to broken Chromium FYI bots.

Original issue's description:
> Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.
>
> The store was used in WebRtcSessionDescriptionFactory to generate certificates,
> now a generator is used instead (new API). PeerConnection[Factory][Interface],
> and WebRtcSession are updated to pass generators all the way down to the
> WebRtcSessionDescriptionFactory instead of stores.
>
> The webrtc implementation of a generator, RTCCertificateGenerator, is used as
> the default generator (peerconnectionfactory.cc:189) instead of the webrtc
> implementation of a store, DtlsIdentityStoreImpl.
>   The generator is fully parameterized and does not generate RSA-1024 unless you
> ask for it (which makes sense not to do beforehand since ECDSA is now default).
> The store was not fully parameterized (known filed bug).
>
> The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
> updated to take a generator instead of a store. But as to not break Chromium,
> the old function signature taking a store is kept. It is implemented to invoke
> the generator version by wrapping the store in an
> RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
> new function signature we can remove the old CreatePeerConnection.
>   Due to having multiple CreatePeerConnection signatures, some calling places
> are updated to resolve the ambiguity introduced.
>
> BUG=webrtc:5707, webrtc:5708
> R=phoglund@webrtc.org, tommi@webrtc.org
> TBR=tkchin@webrc.org
>
> Committed: https://chromium.googlesource.com/external/webrtc/+/400781a2091d09a725b32c6953247036b22478e8

TBR=tkchin@webrtc.org,tommi@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5707, webrtc:5708
Committed: https://crrev.com/d7973ccdb54307ead8f9defba5ad77f929e36153
Cr-Commit-Position: refs/heads/master@{#12948}

[hbos, 2016-05-27 13:08:35]

Created Revert of Replacing DtlsIdentityStoreInterface with
RTCCertificateGeneratorInterface.

[commit-bot: I haz the power, 2016-05-27 13:08:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2020633002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2020633002/1

[commit-bot: I haz the power, 2016-05-27 13:08:58]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-27 13:09:06]

Description was changed from

==========
Revert of Replacing DtlsIdentityStoreInterface with
RTCCertificateGeneratorInterface. (patchset #2 id:20001 of
https://codereview.webrtc.org/2013523002/ )

Reason for revert:
There are more CreatePeerConnection calls than I anticipated/had found in
Chromium, like remoting/protocol/webrtc_transport.cc. Reverting due to broken
Chromium FYI bots.

Original issue's description:
> Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.
> 
> The store was used in WebRtcSessionDescriptionFactory to generate
certificates,
> now a generator is used instead (new API). PeerConnection[Factory][Interface],
> and WebRtcSession are updated to pass generators all the way down to the
> WebRtcSessionDescriptionFactory instead of stores.
> 
> The webrtc implementation of a generator, RTCCertificateGenerator, is used as
> the default generator (peerconnectionfactory.cc:189) instead of the webrtc
> implementation of a store, DtlsIdentityStoreImpl.
>   The generator is fully parameterized and does not generate RSA-1024 unless
you
> ask for it (which makes sense not to do beforehand since ECDSA is now
default).
> The store was not fully parameterized (known filed bug).
> 
> The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
> updated to take a generator instead of a store. But as to not break Chromium,
> the old function signature taking a store is kept. It is implemented to invoke
> the generator version by wrapping the store in an
> RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
> new function signature we can remove the old CreatePeerConnection.
>   Due to having multiple CreatePeerConnection signatures, some calling places
> are updated to resolve the ambiguity introduced.
> 
> BUG=webrtc:5707, webrtc:5708
> R=phoglund@webrtc.org, tommi@webrtc.org
> TBR=tkchin@webrc.org
> 
> Committed:
https://chromium.googlesource.com/external/webrtc/+/400781a2091d09a725b32c695...

TBR=tkchin@webrtc.org,tommi@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5707, webrtc:5708
==========

to

==========
Revert of Replacing DtlsIdentityStoreInterface with
RTCCertificateGeneratorInterface. (patchset #2 id:20001 of
https://codereview.webrtc.org/2013523002/ )

Reason for revert:
There are more CreatePeerConnection calls than I anticipated/had found in
Chromium, like remoting/protocol/webrtc_transport.cc. Reverting due to broken
Chromium FYI bots.

Original issue's description:
> Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.
>
> The store was used in WebRtcSessionDescriptionFactory to generate
certificates,
> now a generator is used instead (new API). PeerConnection[Factory][Interface],
> and WebRtcSession are updated to pass generators all the way down to the
> WebRtcSessionDescriptionFactory instead of stores.
>
> The webrtc implementation of a generator, RTCCertificateGenerator, is used as
> the default generator (peerconnectionfactory.cc:189) instead of the webrtc
> implementation of a store, DtlsIdentityStoreImpl.
>   The generator is fully parameterized and does not generate RSA-1024 unless
you
> ask for it (which makes sense not to do beforehand since ECDSA is now
default).
> The store was not fully parameterized (known filed bug).
>
> The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
> updated to take a generator instead of a store. But as to not break Chromium,
> the old function signature taking a store is kept. It is implemented to invoke
> the generator version by wrapping the store in an
> RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
> new function signature we can remove the old CreatePeerConnection.
>   Due to having multiple CreatePeerConnection signatures, some calling places
> are updated to resolve the ambiguity introduced.
>
> BUG=webrtc:5707, webrtc:5708
> R=phoglund@webrtc.org, tommi@webrtc.org
> TBR=tkchin@webrc.org
>
> Committed:
https://chromium.googlesource.com/external/webrtc/+/400781a2091d09a725b32c695...

TBR=tkchin@webrtc.org,tommi@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5707, webrtc:5708

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

[commit-bot: I haz the power, 2016-05-27 13:09:07]

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