Remove kProtectionKey* and VCMKeyRequestMode.

Remove kProtectionKey* and VCMKeyRequestMode.

Enforces previous kProtectionKeyOnLoss as the permanent method which was
the only one used in use. This simplifies SetVideoProtection and
transition over to SetReceiverRobustnessMode.

BUG=webrtc:1596
R=stefan@webrtc.org

Committed: https://crrev.com/081af25c11aa3015e5da46d64532eb3b9b92f909
Cr-Commit-Position: refs/heads/master@{#9641}

[pbos-webrtc, 2015-07-20 13:27:44]

The CQ bit was checked by pbos@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2015-07-20 13:27:53]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1244753002/1

[pbos-webrtc, 2015-07-20 13:28:49]

PTAL, agree that we can enforce this as the only mode? Otherwise I'll modify the
suggestion to just remove KeyOnKeyFrame (->KeyOnLoss), but I think we can do
without the option. WDYT?

[commit-bot: I haz the power, 2015-07-20 14:26:43]

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

[commit-bot: I haz the power, 2015-07-20 14:26:43]

Dry run: This issue passed the CQ dry run.

[stefan-webrtc, 2015-07-27 13:01:08]

https://codereview.webrtc.org/1244753002/diff/1/webrtc/modules/video_coding/m...
File webrtc/modules/video_coding/main/source/video_receiver.cc (right):

https://codereview.webrtc.org/1244753002/diff/1/webrtc/modules/video_coding/m...
webrtc/modules/video_coding/main/source/video_receiver.cc:396: request_key_frame
= true;
Not sure about this change. I think I'd prefer for the default to be that we
rely on the decoder to return an error and have that as a signal to request a
key frame.

[pbos-webrtc, 2015-07-27 13:05:11]

https://codereview.webrtc.org/1244753002/diff/1/webrtc/modules/video_coding/m...
File webrtc/modules/video_coding/main/source/video_receiver.cc (right):

https://codereview.webrtc.org/1244753002/diff/1/webrtc/modules/video_coding/m...
webrtc/modules/video_coding/main/source/video_receiver.cc:396: request_key_frame
= true;
On 2015/07/27 13:01:08, stefan-webrtc (holmer) wrote:
> Not sure about this change. I think I'd prefer for the default to be that we
> rely on the decoder to return an error and have that as a signal to request a
> key frame.

Right now it's a no-op since this mode was always configured to be used in
ViEChannel.

[stefan-webrtc, 2015-07-27 13:54:09]

On 2015/07/27 13:05:11, pbos-webrtc wrote:
>
https://codereview.webrtc.org/1244753002/diff/1/webrtc/modules/video_coding/m...
> File webrtc/modules/video_coding/main/source/video_receiver.cc (right):
> 
>
https://codereview.webrtc.org/1244753002/diff/1/webrtc/modules/video_coding/m...
> webrtc/modules/video_coding/main/source/video_receiver.cc:396:
request_key_frame
> = true;
> On 2015/07/27 13:01:08, stefan-webrtc (holmer) wrote:
> > Not sure about this change. I think I'd prefer for the default to be that we
> > rely on the decoder to return an error and have that as a signal to request
a
> > key frame.
> 
> Right now it's a no-op since this mode was always configured to be used in
> ViEChannel.

True, let's change this later if needed instead.

lgtm

[pbos-webrtc, 2015-07-27 13:54:25]

The CQ bit was checked by pbos@webrtc.org

[commit-bot: I haz the power, 2015-07-27 13:54:38]

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

[commit-bot: I haz the power, 2015-07-27 15:02:26]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-07-27 15:02:36]

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