RFC: Early mock-up of a xenopsd based on golang libxl bindings

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

https://gitlab.com/martyros/go-xen branch `working/xenops` contains a 
super-basic mock-up of a unix domain xenopsd based on the golang libxl bindings.

To use:

* Install Xen >= 4.14 on your target system

* Make sure you have go >= 1.11 installed

* Clone & build the server

$ git clone https://gitlab.com/martyros/go-xen

$ cd go-xen

$ git checkout working/xenops

Note that this is *not* a fast-forwarding branch.

$ cd xenops/xenopsd

$ go build

$ ./xenopsd

Theoretically this will now accept jsonrpc v1 calls on `/tmp/xenops`.  I 
haven’t dug into exactly what the wire protocol looks like, but you can test 
golang’s version of it by using one of the “client examples”.  In another 
terminal:

$ cd xenops/client-examples

$ go run get-domains-example.co

It should list the currently-running domains and their domain names.

The core of the actual implementation is in go-xen/xenops/xenops/xenops.go.  
Basically, every method you add to the Xenops type of the correct format 
(described in the “net/rpc” documentation) will be exposed as a method 
available via RPC.

The current code only does a Unix socket, but it could easily be modified to 
work over http as well.

Once we have function signatures in the libxl IDL, the xenops methods could all 
be autogenerated, just like the types are for the golang bindings.

It should be noted that at the moment there will be two “layers” of translation 
both ways here: The golang package will be converting rpc into golang 
structures, then the libxl libraries will be converting golang structures into 
C structures; then any return values have to be converted from C structures 
into golang structures, and then converted a gain from golang structures into 
json before being sent back over the wire.  This may or may not be a big 
overhead.

Two things that are currently sub-optimal about the `xenlight` package for this 
use case.

First, although we have a xenlight.Error type, a lot of the xenlight wrappers 
return a generic “error”.  I’m not sure how that will end up being converted 
into json, but we might thing about making the xenlight wrappers all return 
xenlight.Error instead.

Secondly, at the moment the xenlight types are in the same package as the 
function wrappers.  This means that in order to build even the client, you need 
to be able to link against an installed libxl library — even though the final 
binary won’t need to link against libxl at all, and could theoretically be on a 
completely separate host.

Unfortunately the way we’ve structured xenlight, it’s not simple to move 
types.gen.go into its own package, because of the toC and fromC wrappers, which 
*do* need to link against libxl (for the init and dispose functions).  Nick, we 
might think about whether we should make separate toC and fromC functions for 
each of the types, rather than making those methods.

 -George