Revert of [Mojo Video Capture] Introduce abstraction VideoCaptureSystem

Revert of [Mojo Video Capture] Introduce abstraction VideoCaptureSystem (patchset #6 id:160001 of https://codereview.chromium.org/2769543002/ )

Reason for revert:
I think, this patch makes MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (Win7 Tests) flaky.

e.g.
https://uberchromegw.corp.google.com/i/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/58802

MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (run #1):
[ RUN      ] MediaDevicesDispatcherHostTest.GetVideoInputCapabilities
c:\b\c\b\win\src\content\browser\renderer_host\media\media_devices_dispatcher_host_unittest.cc(373): error: Actual function call count doesn't match EXPECT_CALL(*this, MockVideoInputCapabilitiesCallback())...
         Expected: to be called once
           Actual: never called - unsatisfied and active
[  FAILED  ] MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (48 ms)


Original issue's description:
> [Mojo Video Capture] Introduce abstraction VideoCaptureSystem
> 
> This CL is supposed to be a pure refactoring. There should be no changes to
> existing behavior.
> 
> This is part of a series of CLs with the goal of separating the class
> VideoCaptureManager from knowledge of things that are going to be private
> implementation details of the video capture service. The end goal is to have
> VideoCaptureManager talk to an abstraction that can be implemented by either the
> video capture Mojo service or the existing (legacy) in-process implementation.
> 
> Changes in this CL:
> * Move nested struct VideoCaptureManager::DeviceInfo to struct
>   media::VideoCaptureDeviceInfo.
> * Create abstraction VideoCaptureSystem and move caching of
>   VideoCaptureDeviceInfo to there. This allows us to use this functionality in
>   both InProcess and MojoService code paths.
> * Simplify BuildableDeviceCallbacks interface. With the mapping from device_id
>   to descriptor being moved into VideoCaptureSystem, BuildableDeviceCallbacks no
>   longer needs to offer a LookupDeviceDescriptor() method.
> 
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL18.
> 
> BUG=584797
> TEST=
>   content_unittests --gtest_filter="*Video*"
>   content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
> 
> [1] https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxsxWslJ_X-zpOhijvI8/edit?usp=sharing
> 
> Review-Url: https://codereview.chromium.org/2769543002
> Cr-Commit-Position: refs/heads/master@{#461845}
> Committed: https://chromium.googlesource.com/chromium/src/+/8d8a5d278461d098d3481acf52275bb931f834f3

TBR=miu@chromium.org,emircan@chromium.org,mcasas@chromium.org,chfremer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584797
Review-Url: https://codereview.chromium.org/2802553002
Cr-Commit-Position: refs/heads/master@{#461952}
Committed: https://chromium.googlesource.com/chromium/src/+/377d975f2cad5c02157f2436c6d7cf2318c82a51

[tasak, 2017-04-05 02:44:42]

The CQ bit was checked by tasak@google.com

[tasak, 2017-04-05 02:44:42]

Created Revert of [Mojo Video Capture] Introduce abstraction VideoCaptureSystem

[commit-bot: I haz the power, 2017-04-05 02:45:22]

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, 2017-04-05 02:46:34]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1491360282012270, "parent_rev":
"06596a6f56b2b5ce13859d05f5b2a9434ee55a64", "commit_rev":
"377d975f2cad5c02157f2436c6d7cf2318c82a51"}

[commit-bot: I haz the power, 2017-04-05 02:47:32]

Description was changed from

==========
Revert of [Mojo Video Capture] Introduce abstraction VideoCaptureSystem
(patchset #6 id:160001 of https://codereview.chromium.org/2769543002/ )

Reason for revert:
I think, this patch makes
MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (Win7 Tests) flaky.

e.g.
https://uberchromegw.corp.google.com/i/chromium.win/builders/Win7%20Tests%20%...

MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (run #1):
[ RUN      ] MediaDevicesDispatcherHostTest.GetVideoInputCapabilities
c:\b\c\b\win\src\content\browser\renderer_host\media\media_devices_dispatcher_host_unittest.cc(373):
error: Actual function call count doesn't match EXPECT_CALL(*this,
MockVideoInputCapabilitiesCallback())...
         Expected: to be called once
           Actual: never called - unsatisfied and active
[  FAILED  ] MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (48 ms)


Original issue's description:
> [Mojo Video Capture] Introduce abstraction VideoCaptureSystem
> 
> This CL is supposed to be a pure refactoring. There should be no changes to
> existing behavior.
> 
> This is part of a series of CLs with the goal of separating the class
> VideoCaptureManager from knowledge of things that are going to be private
> implementation details of the video capture service. The end goal is to have
> VideoCaptureManager talk to an abstraction that can be implemented by either
the
> video capture Mojo service or the existing (legacy) in-process implementation.
> 
> Changes in this CL:
> * Move nested struct VideoCaptureManager::DeviceInfo to struct
>   media::VideoCaptureDeviceInfo.
> * Create abstraction VideoCaptureSystem and move caching of
>   VideoCaptureDeviceInfo to there. This allows us to use this functionality in
>   both InProcess and MojoService code paths.
> * Simplify BuildableDeviceCallbacks interface. With the mapping from device_id
>   to descriptor being moved into VideoCaptureSystem, BuildableDeviceCallbacks
no
>   longer needs to offer a LookupDeviceDescriptor() method.
> 
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL18.
> 
> BUG=584797
> TEST=
>   content_unittests --gtest_filter="*Video*"
>   content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
> 
> [1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
> 
> Review-Url: https://codereview.chromium.org/2769543002
> Cr-Commit-Position: refs/heads/master@{#461845}
> Committed:
https://chromium.googlesource.com/chromium/src/+/8d8a5d278461d098d3481acf5227...

TBR=miu@chromium.org,emircan@chromium.org,mcasas@chromium.org,chfremer@chromi...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584797
==========

to

==========
Revert of [Mojo Video Capture] Introduce abstraction VideoCaptureSystem
(patchset #6 id:160001 of https://codereview.chromium.org/2769543002/ )

Reason for revert:
I think, this patch makes
MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (Win7 Tests) flaky.

e.g.
https://uberchromegw.corp.google.com/i/chromium.win/builders/Win7%20Tests%20%...

MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (run #1):
[ RUN      ] MediaDevicesDispatcherHostTest.GetVideoInputCapabilities
c:\b\c\b\win\src\content\browser\renderer_host\media\media_devices_dispatcher_host_unittest.cc(373):
error: Actual function call count doesn't match EXPECT_CALL(*this,
MockVideoInputCapabilitiesCallback())...
         Expected: to be called once
           Actual: never called - unsatisfied and active
[  FAILED  ] MediaDevicesDispatcherHostTest.GetVideoInputCapabilities (48 ms)


Original issue's description:
> [Mojo Video Capture] Introduce abstraction VideoCaptureSystem
> 
> This CL is supposed to be a pure refactoring. There should be no changes to
> existing behavior.
> 
> This is part of a series of CLs with the goal of separating the class
> VideoCaptureManager from knowledge of things that are going to be private
> implementation details of the video capture service. The end goal is to have
> VideoCaptureManager talk to an abstraction that can be implemented by either
the
> video capture Mojo service or the existing (legacy) in-process implementation.
> 
> Changes in this CL:
> * Move nested struct VideoCaptureManager::DeviceInfo to struct
>   media::VideoCaptureDeviceInfo.
> * Create abstraction VideoCaptureSystem and move caching of
>   VideoCaptureDeviceInfo to there. This allows us to use this functionality in
>   both InProcess and MojoService code paths.
> * Simplify BuildableDeviceCallbacks interface. With the mapping from device_id
>   to descriptor being moved into VideoCaptureSystem, BuildableDeviceCallbacks
no
>   longer needs to offer a LookupDeviceDescriptor() method.
> 
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL18.
> 
> BUG=584797
> TEST=
>   content_unittests --gtest_filter="*Video*"
>   content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
> 
> [1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
> 
> Review-Url: https://codereview.chromium.org/2769543002
> Cr-Commit-Position: refs/heads/master@{#461845}
> Committed:
https://chromium.googlesource.com/chromium/src/+/8d8a5d278461d098d3481acf5227...

TBR=miu@chromium.org,emircan@chromium.org,mcasas@chromium.org,chfremer@chromi...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584797

Review-Url: https://codereview.chromium.org/2802553002
Cr-Commit-Position: refs/heads/master@{#461952}
Committed:
https://chromium.googlesource.com/chromium/src/+/377d975f2cad5c02157f2436c6d7...
==========

[commit-bot: I haz the power, 2017-04-05 02:47:32]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/377d975f2cad5c02157f2436c6d7...