Add comments reflecting May 17th meeting.

Design:-Node-Messaging-API.md

@@ -23,6 +23,10 @@ This simple system has a few limitations that we want to address:
  3. due to 1 & 2, we cannot build any timeout feature into the node
  4. we know of a use case where an embedder of node-red requires nodes to be strictly one-in, one-out, and that should be policed by the runtime. Putting aside the specifics, we cannot provide any such mode of operation with the current model
 
+> (HN): According to the discussion held on May 17th, 
+> the correlation information among an input message and output messages are expected to be used for logging purpose, and
+> and a output message correlate with the latest input message received.
+
 This design note explores how this mechanism could be updated to satisfy these limitations.
 
 The original draft of this node set out three options. Through the process of writing the options, I've chosen my preferred approach. I have left the other two options at the bottom of the note for reference.
@@ -69,14 +73,25 @@ Usage            | Meaning
  - `node.send` should not be used in this case as its use will stop the runtime from being able to correlate message received with message sent. We _probably_ won't enforce this - tbd.
  - `node.error` can still be used as a handler may need to log multiple errors before completing.
 
+> (HN): According to the discussion held on May 17th, 
+>       if `send` and `done` is omitted from the handler arguments (i.e. original form of handler is used), `done` is implicitly called after callback execution.
+
 **What if `done` is never called?** - If a handler is registered that takes the `send` and `done` arguments, the runtime requires it to eventually call `done` for each message received. Not calling `done` should be considered a bug with the node implementation. The question is what happens if it doesn't get called. 
 
 The easy option is to do nothing. But that will allow buggy implementations to exist, so we should avoid this option.
 
 The right approach will be to timeout the function. A timeout would be considered an error and logged as such. The runtime will set a default timeout of **30 seconds (TBD)**. A node will be able to set its own timeout value by setting a property on itself (`this.TIMEOUT = 60000` (TBD)). This also allows a future extension where a user can set custom timeout values per node in the editor (but this proposal does not extend that far today).
 
+> (HN): According to the discussion held on May 17th, 
+>       fixed timeout value may lead to unpredictable behavior of flows because execution time and order may vary for each execution.  So, we make default timeout behavior of nodes off and add allow specifying timeout of each node independently using new API, say `node.setTimeout(<value>)`.  Global setting of timeout, e.g. `RED.setNodeTimeout(<value>)`, is also useful.
+
 **What if a node that has been timed out then wakes up and calls `done` or `send`?** - should the runtime then block a timed out node from calling `send` or `done` (at least... prevent any messages it then sends from being passed on? I can see use cases for both allowing the message to pass on and for stopping it. Does this need to be a per-node policy? Or a choice made in the editor? Hmmm.
 
+> (HN): According to the discussion held on May 17th, 
+>       correct handling of early timeout of node is different for each flow.  So, we assume timeout of a node throws exception and can be caught by `catch` node.
+
+> (HN): Note: Because processing of `send` and `done` is on critical path of node processing, we must take care of reducing their execution overhead on implementation.
+
 ---
 
 ### Alternative Option 1: Add a `node.complete` function - v1