Feature/autobahn

This patch adds support for requesting and shutting down
connections via the Autobahn BoD.

This initial version hardcodes most connection parameters due
to lack of support for such parameters in OpenNaaS (bandwidth,
vlan ID, lifetime, etc). Once OpenNaaS BoD support has been
extended, the driver can be extended too. Consider this driver
a use case to drive the OpenNaaS BoD support forward.

The initial version lacks support for queue transactions. This
is because the Autobahn webservice is stateless and does not
support explicit transaction demarcation. Poor man's
transaction support without isolation could be achieved
by rolling back the creation/release manually (by releasing
or recreating), although there is no guarantee that a released
resource can be rereserved (it may have been taken by other
reservations). Implementing this is not straightforward as
OpenNaaS lacks support for a queue context or some other
way of maintaining state accross actions that are part of the
same queue execution. Once such support is added the poor man's
transaction support can be implemented.

The Autobahn driver requires access to both the user access
point and adminstration webservice interfaces of Autobahn.
These are by default published on the same port, so the
protocol context URI is simply the base URI for both services.
Eg:

protocols:context bod:autobahn autobahn http://autobahn.example.org:8080/autobahn/

The driver will internally append "uap" or "adminstration" to
this URI.

Access to the administrative interface is required as it is
otherwise not possible to query the list of existing reservations.

Note that OpenNaaS provides no user interface for inspecting the
model of the BoD resource. You either have to know the network
interfaces of Autobahn (by using the Autobahn GUI) or you have
to inspect the OpenNaaS log files.

Note that the Autobahn reservation process is asynchronous. When
OpenNaaS executes the request action, the driver only submits a
reservation request. Setting up the reservation can possible take
minutes (in multidomain setups). Therefore the driver will create
a link in the resource's model for any reservation not in a
finished state. Autobahn does allow a callback to be registered,
but this requires that OpenNaaS implements a particular webservice
and that there is connectivity from Autobahn to OpenNaaS (no
firewall). In either case, OpenNaaS doesn't know about such
asynchronous changes, so even if we implemented the callback
interface, we wouldn't be able to react to reservation changes
outside the execution of a queue.

As mentioned above, a reservation is represented as a link in
the model. It is set on the source's linkedTo field. Note that
Autobahn supports creating multiple reservations between the
same two ports (interfaces): Each reservation can use a
different VLAN ID. Since an interface in OpenNaaS only has one
linkedTo field, such reservations cannot be represented in
OpenNaaS.

Note that the NSI protocol treats interfaces differently: NSI
uses the concept of a network service endpoint, and such an
endpoint incorporates the VLAN. Ie VLAN isn't a property in NSI.
Instead, if you have two interfaces A and B, and a VLAN range
of 1000-1002, then you have service endpoints A-1000, A-1001,
A-1002, B-1000, B-1001, B-1002 (or whatever naming scheme the
NSA chooses to implement). In that case you can indeed only
have one connection between two endpoints (which would be
interfaces in OpenNaaS). The problem here is that often one
cannot connect all endpoints, eg A-1000 and B-1001 are not
connectable (depends on the hardware, of course). My point is
that BoD systems are sufficiently different from each other
that it may become difficult to make a common abstraction
in OpenNaaS (or that it will require extensive configuration
info to map between OpenNaaS' representation and the
representation in the BoD system - something that would be
a pain to maintain).

Authentication in Autobahn is disabled by default and it not
supported by the initial revision of this driver.

Integration tests are missing. These will be added soon.