media: Support creation and SetCdm() for mojo based CDM.

media/mojo/interfaces/content_decryption_module_factory.mojom

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module mojo;
+
+import "media/mojo/interfaces/content_decryption_module.mojom";
+
+// An interface to request a ContentDecryptionModule service.

[ddorwin, 2015/01/06 00:57:28]

Should this file have more detailed comments, such as for the parameters?
Specifically, cdm_id might not be obvious.

[xhwang, 2015/01/06 19:54:54]

Done.

+interface ContentDecryptionModuleFactory {
+  Create(string key_system,
+         string security_origin,
+         int32 cdm_id,

[ddorwin, 2015/01/06 00:57:28]

Can we have the factory generate an ID in the CDM before outputting it?

This solves the multiple-client problem and avoids clients passing in
conflicting values.

Regarding the original reason (no synchronous Mojo calls), perhaps we can return
the cdm_id and cdm together here.

[xhwang, 2015/01/06 19:54:54]

I looked at this more closely and IIUIC we can't get any value/struct back from
a mojo service  synchronously. We can only get requested services back
synchronously. This is why we are providing a client side |cdm_id|. (+jamesr to
double check on this.)

I didn't realize this yesterday (I blame the holidays :) Sorry for the
confusion.

[ddorwin, 2015/01/07 00:37:13]

So |cdm| is a special output parameter? That seems very odd.

[jamesr, 2015/01/07 02:22:06]

Uhh, I don't really understand.  All mojo calls are asynchronous.  You can
connect to a service and start using it immediately since connecting to a
service means allocating a message pipe and passing one handle which will
asynchronously arrive at the other end.  In the meantime, you can write into the
other handle.  But that's not the same thing as "getting something
synchronously"

What's the problem you are trying to solve here?

+         ContentDecryptionModule&? cdm);
+};