Implements JS bindings for mojo data pipe.

third_party/WebKit/Source/core/mojo/MojoHandle.idl

Index: third_party/WebKit/Source/core/mojo/MojoHandle.idl
diff --git a/third_party/WebKit/Source/core/mojo/MojoHandle.idl b/third_party/WebKit/Source/core/mojo/MojoHandle.idl
index 78a49ed0fd4be0c51ac155307da18422f4845550..f8daea3fe03d5c0ff692c9aab7ce66284c3811e7 100644
--- a/third_party/WebKit/Source/core/mojo/MojoHandle.idl
+++ b/third_party/WebKit/Source/core/mojo/MojoHandle.idl
@@ -15,6 +15,11 @@ callback MojoWatchCallback = void (MojoResult result);
     MojoResult writeMessage(BufferSource buffer, sequence<MojoHandle> handles);
     MojoReadMessageResult readMessage(optional MojoReadMessageFlags flags);
 
+    // TODO(alokp): Create DataPipeHandle, a subclass of MojoHandle
+    // and move the following member functions.
+    MojoWriteDataResult writeData(BufferSource buffer, optional MojoWriteDataFlags flags);

[yzshen1, 2017/03/07 17:56:39]

Is it the plan to add two-phase read/write in a follow-up change?

[alokp, 2017/03/07 19:34:20]

Do you mean MojoBegin[End]ReadData? If so, yes we can add in a later patch or
whenever needed. I could not find any current usage.

+    MojoReadDataResult readData(MojoReadDataFlags flags, optional unsigned long numBytes, optional BufferSource buffer);

[alokp, 2017/03/07 05:48:58]

yzshen/jbroman: MojoReadData is pretty heavily overloaded. It supports four
operations - querying, discarding, reading, and peeking - via MojoReadDataFlags.

I have tried to fold all these four operations into a single readData API, but
it probably makes sense to separate them into four different functions:

MojoReadDataResult queryData();

MojoReadDataResult discardData(MojoReadDataFlags flags, unsigned long numBytes);

MojoReadDataResult readData(MojoReadDataFlags flags, unsigned long numBytes,
BufferSource buffer);

MojoReadDataResult peekData(MojoReadDataFlags flags, unsigned long numBytes,
BufferSource buffer);

WDYT?

[jbroman, 2017/03/07 16:01:44]

I don't feel strongly here.

To me this is a slightly clearer API, as long as the mapping to the Mojo
primitives is still clear (it is to me) and doesn't limit the future evolution
of the Mojo API (I don't see that it does).

Interestingly, the Java bindings seem to go halfway and provide discardData and
readData.

[yzshen1, 2017/03/07 17:56:39]

I am fine with this. +CC rockot for API discussion.

[Ken Rockot(use gerrit already), 2017/03/07 18:09:51]

Seems reasonable to me.

[alokp, 2017/03/07 19:34:20]

Thanks for the feedback. I split readData into three functions - queryData,
discardData, and readData (also supports peekData). PTAL.

+
     // TODO(alokp): Create SharedBufferHandle, a subclass of MojoHandle
     // and move the following member functions.
     MojoMapBufferResult mapBuffer(unsigned long offset, unsigned long numBytes);