add interceptors to RPCs and apply authorization logic

[mejohnnaylor]

let's start with GetValue.

expected behavior:

• the GetValue payload includes the target parameter's oid as a json pointer relative to device[slot]/params - we're just using slot 0 for now
• the interceptor must check that the scope of the parameter is included in the scopes of the bearer token
• see the authorize method to see how to get and unpack the bearer token
• this task will make the authorize method redundant so calls to it and the method itself should be deleted by this task

A parameter's access scope is specified by:

• its access_scope member, if present. If not...
• its parent parameter's access scope, if that doesn't have one...
• the default access scope specified at the device level

How I'd do this...

am = device.default_access_scope;
while (navigating to param) {
   if (param.access_scope isn't an empty string)
     am = param.access_scope;
   if (we navigated to the end of the path)
     navigating to param = false
  else
      param = param[child oid]
}

The main work here is reading up on grpc interceptors and figuring out how to use them. They're basically middleware.

[mejohnnaylor]

... and as middle ware, it'd be good if it could pass some of the work done to the next layer - e.g. the interceptor is going to have to get a ParamAccessor to do it's job, based on the oid in GetValue. This work should be reused, probably by altering the request that gets passed to the next layer to include the relevant ParamAccessor*

[mejohnnaylor]

good progress - need to finish ahead of NAB.

[mejohnnaylor]

@johndanenRV reported that gRPC has better built-in authz features that we should consider using. It works directly in the server context which is much easier than in the interceptor.