this is both to prevent stealing api keys (attacker will have to insert
their own API keys and leave a trace), but also prevent a possible side
channel attack (unlikely)...

This will be followed by an gentoken command or similar that uses
this as a jump host command..

this allows all comms, including generating an access token to happen
over https allowing a single entry point to the entire system...

This may come back in the future, but it will be in BoardImpl, and will
contain more state such that a resume will have all the attribute's
current state in addition to checkout and the like.

This makes the separation between the implementation and the API
more clean, as before the API was doing too much work..

for reserve/release, relocating this logic out of the API logic.

This is not complete as it calls the board relase, but that doesn't
actually do everything needed...  work needs to be done to move the
logic from the API into the board proper...

This prevents allowing users to spam the controller's stderr...
In the future this may be forwarded as it's own stream...

really need to get code formatting added to the pipeline..

This was pretty tricky to get working w/ the pipes and mocking
stdin/stdout, but w/ some pipes it's working..  There is an unclosed
transport that needs to be investigated though.

also more direct testing in the jail, and allow ssh in to the jails
w/o having to do crazy nat...

This means the controller should/can live w/ only the http(s) front
end exposed...  ssh can be done via a proxy command the runs sshd -i..
or commands can be directly interacted with....  Future may support
running commands via a pty, allowing window change events to be passed
allowing use of something like xterm.js in a web browser...

aiokq is no longer needed as we are using a database...

if non-provided...

around as addkeys should be smaller than attrs...

or bootup messages) are escaped...