Review RKS conventions, especially related to list of nodes and streams

[laroque]

Things in psyllid and dragonfly are just a bit different, maybe that's fine, maybe it would be nice to make things more uniform. We're punting for now, but wanted to not forget the ideas.

Summary of a slack discussion (edited):

Ben:

i have two possible RKS now:
<queue>.stream-list: returns a param_array of stream names
<queue>.node-list.<stream>: returns a param_array of node names
maybe that is fine
...

it felt more natural to me that you’d be able to get any of these:
<queue>.element_list: list of streams
<queue>.element_list.<stream>: list of nodes
<queue>.active_config: everything (doesn’t exist)
<queue>.active_config.<stream>: everything in the stream (also doesn’t exist)
<queue>.active_config.<stream>.<node>: everything for the node
maybe also:
<queue>.element_list.<stream>.<node>: returns list of configurable params

Noah:

i think part of the problem is that the way psyllid is organized as a set of objects with different responsibilities doesn’t exactly correspond to the set of RKS

Ben:

yeah, in dripline-python i deal with that by having a single message queue with multiple top-level bindings, so the psyllid_cha queue may bind psyllid_cha_daq.* and psyllid_cha_streams.* (or whatever makes sense). Then it uses the RK (not RKS) to decide which object handles the request. Every object which handles requests (probably the most correct abstract def of an endpoint) then deals with parsing an RKS and binding that to a function call etc.