GitLab

- to contain all graph-related updates
- leaving other elements untouched (whitespace-commits excluded)

Host-API changes due to INodeID
OverlayContact API changes
(this update will most likely break some code. Please merge the current
master into your projects for most fixes)

- implemented in current overlay master

in the SiSInformationConsumer

SiS: Data callback contains InfoProperties

SiS: Requests need to contain a timeout

Updated SiS-API based on Nodes and Edges

The new SiS-API is more compatible to the nodes and edges introduced by the graph-API and furthermore gets rid of array-based SiSTypes for multi-node states.

See merge request !18

SiS: component provides an INodeID

SiS: InformationProperties-Source no longer limited to HostComponents
SiS: minor updates to javadocs, added a Test-SiSType for JUnit

SiSType-abstraction. This enables the SiS and monitoring to attach
metrics to an abstract node or edge object, which is usefull during
collection and dissemination or aggregation.

attach multiple metrics/states to an INode or an IEdge

- weight of edges is now realized via the property-interface

SiS: added some toString methods

topology monitoring with the SiS
Added IOverlayContact to the APIs
Added new SiS-Types based on updated GraphAPI

SiS: Refactored typing in the SiS (added static "SiSTypes"-class)
SiS: Continued the InformationProvider-Interface
SiS: Fixed some generics-related issues

using array-types instead
Adding informationProperties as base for requests and info providers to
specify potential QoS-attributes of the information

Used the ControllableNetInterface in Bypass

- isStopped is true, if the OP is not yet started

- added a TopologyID instead of String identifiers
- added an UnderlayTopologyProvider
-- support for topologies based on the PHY (e.g., ethernet
connectivity), with or without offline nodes
-- support for (potential) topologies assuming a given communication
range (only for broadcast PHYs)

continued, please create the respective branches and add a pull request.
However, API changes are only merged, if there is working code
(overlay/service) that actually *uses* the respective API.