Config Service bugfixes, Admin API and Gateway Location RPC

[jeffgrunewald]

! Depends on helium/proto#288

This doozy introduces several bug fixes in the implementation of the streaming RPCs, retrieving records from the DB and decoding their types, integer size changes in the upstream proto dependency, and devaddr constraints records

• Introduces devaddr constraint bounds checking when attempting to add new devaddr ranges to routers
• Implements the Gateway service's Location rpc
• Implements the Admin service's rpcs and an AuthCache shared between all the services for efficient validation of administrative requests
• Restructures the region_params management rpc underneath the Admin service (formerly under the Gateway service)
• Extends the docker-compose stack to include a mock node-follower service for easier testing

[andymck]

A lot going on in here but on an initial pass lgtm.

One observation is that we dont appear to have any tests for the config service which may bite at the client integration phase

[andymck]

is this check not redundant, in that if the pub key is invalid wont it already be caught at the sig verification on line 75?

[jeffgrunewald]

Good question but these are checking different keys/things.
They function on line 75 is checking the request to add the new key was signed by an already-registered key (the default key in the db or any admin keys saved to the db) so it would fail if it attempted to validate the request with the key being submitted to the add_key method.
this check validates the key you’re trying to register is a valid key worth saving and also converts the bytes to a PublicKey in order to do the follow up check that it’s a valid key for the network this config instance is servicing (mainnet vs devnet)

[jeffgrunewald]

A lot going on in here but on an initial pass lgtm.

One observation is that we dont appear to have any tests for the config service which may bite at the client integration phase

I agree with you; looking forward to wrapping all of my DB accessors in a trait i can test from outside the rpc methods

[michaeldjeffrey]

My understanding right now is only HPR's will be requesting gateway locations.

[jeffgrunewald]

@madninja and i are discussing whether or not this needs to become a more generic metadata method for retrieving any on-chain data about a hotspot, inclusive of the asserted location but that would be either primarily or exclusively for the other oracles so between that and the HPRs still under the umbrella of "network infrastructure" so likely authenticated but we don't currently authenticate any requests the oracles make (they only request from their host-local blockchain-node instance) so request signing would be a new requirement for them