Fix some bad assumptions in the find_next_link_in_path() function,
which allowed me to remove the two totally wrong hacks I put in
earlier

These 'fixes' are almost certainly wrong, but they may help
work around a short-term problem.

Currently only honored for inter-switch links, and only when doing
the full switch graph search.

Not yet plubmed through to the parser.

The way to turn on full-switch search has now changed: no
compile time option necessary, but now pass -S on the command line
insetead.

Everything in the new BFS is now allocated on the heap, and should
be properly freed when finished - much lower chance of memory
leaks than there was before.

Tracks individual links between switches, so that we can use more
than one, and does not compute a spanning tree, so it will use
non-tree edges in the topology.

Terribly slow, since it does a depth-first search for every
single attempt to resolve inter-switch links

Compile with -DFULL_SWITCHGRAPH to get this behavior.

Has received only minimal testing, probably broken in some cases.

Probably leaks memory like there's no tomorrow.

Does not check link types, or handle phys links that cannot have
multiple virt links on them.

by Hussam.

reported by Hussam.

We never documented whether returned strings for values whose
length is >= the buffer length passed in are null-terminated or not.
Previously, there were not, but most of our callers never checked.
Hence, we now force null termination.

Note that if someone passes a bogus length value, this will
now blow up where it formerly might not have.  I consider this a
value-added debugging feature...

Note also that this is unrelated to recent stated problems, but turned
up while looking for that bug!

If downloading big blobs, /var/tmp can fill up.

PREPARE means we are reloading the disk to a default state, so no custom
MBRs allowed.

We want to make sure that old MBR, superblocks, etc. are cleaned from the disk
before attempting to load the default image.

moving the event system interactions into a child process, which
hopefully isolate the cause to either the event system or something
else entirely.

(orphaned) by the protogeni code.

Client-side builds again, but haven't got node to boot correctly.
Need to get pubsubd installed correctly as a service in place of elvind.

to supply the fully specified rspec to both CMs, my changes permit you
to specify only the component_manager_urn for the remote side.

When you start the sliver, the CMs contact each other to resolve the
slice (get the manifest), find the actual node in the manifest, and
resolve that node to get the control network.

This even allows for fully unbound rspecs to be supplied, as long as
the component_manager_urn is specified.

error and no output is provided. Helpful.

Return the manifest when resolving a slice.

Start/Stop methods from its Start/Stop

experiment before it is wiped out for good.

running, so that we do not start multiple times.

silly to do this in long running daemons.