Add usb_service::UsbDeviceFilter class for device matching.

Add usb_service::UsbDeviceFilter class for device matching.

This class stores criteria for selecting USB devices. A device can be
matched by its vendor and product IDs, and the interfaces that it
implements.

BUG=346953
TBR=satorux@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=289370

[Ken Rockot(use gerrit already), 2014-08-11 20:18:45]

lgtm

https://codereview.chromium.org/462753002/diff/1/components/usb_service/usb_d...
File components/usb_service/usb_device_filter.h (right):

https://codereview.chromium.org/462753002/diff/1/components/usb_service/usb_d...
components/usb_service/usb_device_filter.h:39: bool vendor_id_set_ : 1;
Alternatively consider using scoped pointers for the actual values; then you
don't need a presence flag for each of them.

Though your approach saves on memory allocation and usage, I think it becomes a
little repetitive when adding new filter fields (because adding one really means
adding two).

A good compromise would be to build something like an OptionalValue<T>
structure, which uses a little more space than this (no packed bits for presence
flags) but wouldn't require the additional heap allocations of using scoped_ptr.

Of course at that point I'm not sure the extra noise of a new OptionalValue type
is worth the saved allocations, bringing me back to scoped_ptr.

Then again maybe I'm just over-thinking this.

[Reilly Grant (use Gerrit), 2014-08-11 20:30:40]

On 2014/08/11 20:18:45, Ken Rockot wrote:
> A good compromise would be to build something like an OptionalValue<T>
> structure, which uses a little more space than this (no packed bits for
presence
> flags) but wouldn't require the additional heap allocations of using
scoped_ptr.

I agree completely. There's boost::optional which will make it into C++ at some
point. Out of scope for this change though.

[Reilly Grant (use Gerrit), 2014-08-11 21:09:01]

I found a logic error in manual testing that would have been caught with more
exhaustive unit tests so I've added those.

[Reilly Grant (use Gerrit), 2014-08-12 17:47:59]

Had to add UsbDevice::RequestUsbAccess to the mock so that the tests would
compile on Chrome OS. Took this opportunity to fix the spelling (acess ->
access).

[Reilly Grant (use Gerrit), 2014-08-12 19:39:18]

Adding dgozman and satorux1 to review Android and DBus-related files that
changed as a result of the spelling fix.

[Ken Rockot(use gerrit already), 2014-08-12 19:42:18]

everything else still lgtm

[Reilly Grant (use Gerrit), 2014-08-12 21:35:01]

The CQ bit was checked by reillyg@chromium.org

[commit-bot: I haz the power, 2014-08-12 21:37:34]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reillyg@chromium.org/462753002/100001

[Reilly Grant (use Gerrit), 2014-08-12 21:46:14]

The CQ bit was unchecked by reillyg@chromium.org

[dgozman, 2014-08-13 13:51:18]

chrome/browser/devtools lgtm

[Reilly Grant (use Gerrit), 2014-08-13 18:07:15]

The CQ bit was checked by reillyg@chromium.org

[commit-bot: I haz the power, 2014-08-13 18:09:10]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reillyg@chromium.org/462753002/100001

[commit-bot: I haz the power, 2014-08-13 19:55:01]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[commit-bot: I haz the power, 2014-08-13 20:53:10]

Committed patchset #3 (100001) as 289370