Add Mojo IPC for seeding new Renderer with Browser's cached blob state.

blimp/engine/mojo/blob_channel.mojom

Index: blimp/engine/mojo/blob_channel.mojom
diff --git a/blimp/engine/mojo/blob_channel.mojom b/blimp/engine/mojo/blob_channel.mojom
index 0960916fea10655f4e3511b8e2c1684108c08ace..73545061e3b0d999853582c56c8ce175dcdf2d56 100644
--- a/blimp/engine/mojo/blob_channel.mojom
+++ b/blimp/engine/mojo/blob_channel.mojom
@@ -4,7 +4,19 @@
 
 module blimp.engine.mojom;
 
+struct CacheStateEntry {
+  // The non-human-readable ID of the cache item.

[Wez, 2016/06/21 00:33:33]

nit: Is it relevant that it's not human-readable?

[Kevin M, 2016/06/21 21:23:51]

I think so. We convert this ID to hex for logging, so there might be some
expectation from developers that the same ID will be used in both places.

[Wez, 2016/06/22 19:54:23]

Hmmm; I'd argue that BlobId is intrinsically binary, and the fact that we log
hex is just that nothing else would make sense, but OK :)

+  string id;
+
+  // True if the cached item exists on the remote end of the BlobChannel.
+  bool is_replicated;

[Wez, 2016/06/21 00:33:33]

was_delivered, to match the terminology below?

[Kevin M, 2016/06/21 21:23:51]

Done.

+};
+
 interface BlobChannel {
+  // Gets the list of cache keys and their replication status in the
+  // browser process' BlobCache.
+  GetCacheState() => (array<CacheStateEntry> items);

[Wez, 2016/06/21 00:33:33]

You're calling this CacheStateEntry but then the parameter is "items" - should
it be "cache_state"?

[Kevin M, 2016/06/21 21:23:51]

Done.

+
   // Stores the blob |id| in the BlobCache.
   // TODO(kmarshall): Use shared memory for more efficient data transfer, see
   // crbug.com/614564 .