[VOL-2164] Update rw-core to use the Async Kafka API

This commit consists of the following:

1. Process per-device requests in the Core in the order they are
received. If there are lots of requests on a given device then
there will be some latencies introduced due to ordering.  With
recent changes in the model along with keeping the request lock
to a minimal then these latencies are reduced.  Testing did not
show and noticeable latencies.

2) Keep the request lock from the moment a request started
processing to the moment that request is sent to kafka (when
applicable).  Adapter responses are received and processed
asynchronously. Therefore, an adapter can takes all the time it
needs to process a transaction.  The Core still has a context
with timeout (configurable) to cater for cases where the adapter
does not return a response.

3) Adapter requests are processed to completion before sending a
reponse back to the adapter.  Previously, in some cases, a
separate go routine was created to process the request and a
successful response is sent to the adapter.  Now if the request
fails then the adapter will receive an error. The adapter
requests for a given device are therefore processed in the
order they are received.

4) Some changes are made when retrieving a handler to execute
a device state transition.  This was necessary as there was some
transition overlap found.

Update after multiple reviews.

Change-Id: I55a189efec1549a662f2d71e18e6eca9015a3a17
diff --git a/rw_core/core/grpc_nbi_api_handler.go b/rw_core/core/grpc_nbi_api_handler.go
index eaf8fac..0196f35 100755
--- a/rw_core/core/grpc_nbi_api_handler.go
+++ b/rw_core/core/grpc_nbi_api_handler.go
@@ -23,6 +23,7 @@
 	"errors"
 	"io"
 	"sync"
+	"time"
 
 	"github.com/golang/protobuf/ptypes/empty"
 	da "github.com/opencord/voltha-go/common/core/northbound/grpc"
@@ -58,8 +59,8 @@
 	packetInQueueDone         chan bool
 	changeEventQueueDone      chan bool
 	coreInCompetingMode       bool
-	longRunningRequestTimeout int64
-	defaultRequestTimeout     int64
+	longRunningRequestTimeout time.Duration
+	defaultRequestTimeout     time.Duration
 	da.DefaultAPIHandler
 	core *Core
 }
@@ -138,7 +139,7 @@
 // timeout value (in the event this Core dies the transaction times out in the dB causing the other Core in the
 // core-pair to proceed with the it).  If the device is not owned then this Core will just monitor the transaction
 // for potential timeouts.
-func (handler *APIHandler) takeRequestOwnership(ctx context.Context, id interface{}, maxTimeout ...int64) (*KVTransaction, error) {
+func (handler *APIHandler) takeRequestOwnership(ctx context.Context, id interface{}, maxTimeout ...time.Duration) (*KVTransaction, error) {
 	timeout := handler.defaultRequestTimeout
 	if len(maxTimeout) > 0 {
 		timeout = maxTimeout[0]
@@ -154,9 +155,9 @@
 			log.Warnw("getting-ownership-failed", log.Fields{"deviceId": id, "error": err})
 			return nil, errorIDNotFound
 		}
-		acquired, err = txn.Acquired(ctx, timeout, ownedByMe)
+		acquired, err = txn.Acquired(ctx, timeout.Milliseconds(), ownedByMe)
 	} else {
-		acquired, err = txn.Acquired(ctx, timeout)
+		acquired, err = txn.Acquired(ctx, timeout.Milliseconds())
 	}
 	if err == nil && acquired {
 		log.Debugw("transaction-acquired", log.Fields{"transactionId": txn.txnID})
@@ -366,7 +367,7 @@
 		if handler.isOFControllerRequest(ctx) {
 			//	Since an OF controller is only interested in the set of logical devices managed by thgis Core then return
 			//	only logical devices managed/monitored by this Core.
-			return handler.logicalDeviceMgr.listManagedLogicalDevices()
+			return handler.logicalDeviceMgr.listManagedLogicalDevices(ctx)
 		}
 	}
 	return handler.logicalDeviceMgr.listLogicalDevices(ctx)