media: Add ProvisionFetcher mojo interface and implementation.

media/mojo/interfaces/provision_fetcher.mojom

+// Copyright 2015 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 media.interfaces;

[Ken Rockot(use gerrit already), 2015/11/24 17:35:58]

BTW: I think we'd like to standardize on .mojom for module suffixes rather than
.interfaces. I'm not asking you to change this here or update all media mojom
now, but it might be worth at least filing a bug to update these names over
time.

[xhwang, 2015/11/24 19:43:21]

I asked about this before and at that time there was no standard. That's why we
are following some existing code and use "interfaces" as our standard.

So what's the new standard now?

[Ken Rockot(use gerrit already), 2015/11/24 20:05:29]

Indeed, and totally understandable
Yeah there were a lot of ultimately unresolved discussions around whether to
have any convention at all, or whether the impls should be in an inner impl
namespace, or whatever.

I think there's now a consensus that it's beneficial to have an inner namespace
for mojom types. Given that, it's only a question of what conventional naming to
use. Other components (such as mus) are going with mojom for that name, and
given that len("mojom") < len("interfaces"), I think mojom wins in the long term
:)

Again, not a big issue, but we should be eventually consistent across src

+
+// An interface to retrieve provision information for Android MediaDrm.
+// See Android documentation about MediaDrm provisioning:
+// https://developer.android.com/reference/android/media/MediaDrm.ProvisionRequest.html
+
+interface ProvisionFetcher {
+  // Requests the provision information with |default_url| and |request_data|
+  // and returns |result| and the |response|. The input parameters |default_url|
+  // and |request_data| corresponds to Java class MediaDrm.ProvisionRequest.
+  // |response| will be null iff |result| is false.

[Ken Rockot(use gerrit already), 2015/11/24 17:35:58]

Why bother having |result| at all if |response| is nullable and (result ==
!!response)?

[xhwang, 2015/11/24 19:43:21]

That would work. But personally I'd like to be explicit. Also this matches the
C++ interface, where you don't have a nullable string. You could use empty
string to mean "failure" but again I feel that's confusing.

+  Retrieve(string default_url, string request_data)
+      => (bool result, string? response);
+};