Previously, we'd send one interface_version event for "ei_handshake"
immediately but all others after the client requests handshake.finish.
This was too confusing to document and not clear how it would work, so
let's make this simpler by splitting it up.
There is now a handshake_version event from the server, sent immediately
on connection that denotes the maximum version number for the interface.
And a handshake_version request from the client which must be the first
one by the client.
These were previously (1 << cap) for convenience but that results in the
capability mask on the wire starting at 2 - which is a bit awkward.
Lets shift them down by one so we start the mask at 1.
Add another run to the XML parser so we parse enums before Arguments
that cross-reference enums from other interfaces.
This also fixes a type bug - the enum name string was passed to
Argument.create() as Enum and no-one noticed.
Because we currently only run the test suite in valgrind, we skip the
python test suite there (we don't want to valgrind python itself, too
messy).
Fix this by specifically excluding the python test suite and having a
separate job that just runs that suite instead.
And because the protocol test suite needs the directory to the
eis-demo-server and isn't smart enough to split spaces correctly, let's
change the builddir to just that.
This tests the protocol layer which is hard to test using libei/libeis.
Similar to the generated C bindings we compile a eiproto.py file that is
then used in the test to talk protocol directly to the eis-demo-server
that we start up.
By sending the specific messages and checking things happen as we expect
on the socket we can verify that the EIS implementation is correct (and
robust enough).
In theory this could also be used to test some other binary with an EIS
implementation and the scaffolding is there to set LIBEI_TEST_SERVER to
that binary. Wether this works is untested though...
No real functional changes, this just changes the message header to be
header = [object_id, msglen << 16 | opcode].
The only difference to the wayland protocol is now the fixed vs float
but otherwise tools that can print/debug/mangle the wayland protocol
should be easily adjustable for this protocol too..
