They weren't keeping track of total bandwidth on switches. Clearly,
the fact that this is being done in the parsers and not the tb_pnoce
class means that some re-factoring is in order.

(Note: backported from the assign-cleanup branch)

We were already ignoring them if they were 'mutliplex_okay',
but we should always ignore them - there's no need for the physnode
to have a physical interface that can satisfy them.

Fix bookkeeping in the unassigned_nodes structure in the code
that does reverts; without this, we cannot keep annealing after
a revert. Normally, using the default compile time options, we
don't do this, which is why this bug went unnoticed.

On a related note, turn FINISH_HILLCLIMB (which does keep annealing
after reverting, at the end) into a command line option (-C) instead
of a compile-time option.

We were leaking the final path that we found; this means we're now
making a copy of that path that gets freed up right away, but this
seems like the simplest way to keep the code structure relatively
simple.

Also add some debugging code that can be used to trigger a warning or
assert if a memory leak occurs in this code.

Have I mentioned that I hate it when library developers move their
headers around? Change the location of the property_list.hpp header
to a macro and add a new -DNEWER_BOOT define that swtiches this to
the newer location.

Not automatically detected yet; should be checked in configure.

Formulate the temperature_guard clause so that if the temperature
goes to nan, the check against the temperature guard will succeed.

Turns out there is a better way to handle this, to be committeed
in next commit.

This reverts commit c4f7467f.

If there is a temperature step in which no solutions are accepted,
then the temperature will not change. If this happens above the guard
temperature, then we will get stuck in an infinite loop, since we will
never hit the guard. Normally, this would get taken care of by the
regular termination condition, but we've superseded that with the
guard.

So, add in a very specific check that, if this even happens, turns
off the guard so that we will terminate.

This implements a 'temperature guard' - annealing will not stop before
reaching this temperature. This is an attempt to prevent assign from
giving up when it reaches large local minima

Re-work the way that pclass bookkeeping is done, to fix a couple of
bugs with dynamic pclasses (static types were not being handled
correctly, and in some cases, it was possible for a node to get
removed from all pclasses, including its own)

Note: While this has received some testing, it does have the potential
to break things, even for 'regular' pclasses, so for now, use with
care.

Merge branch 'assign-spantree' of git-public.flux.utah.edu:/flux/git/users/ricci/emulab-devel into assign-spantree

Extended the never_multiplex flag so that it works not only
on switch to switch links, but on links from edge nodes to
switches as well.

I need to slightly rework the rspec for component_hops.

This is just a quick hack to make the annotated RSpec validate, since
this attribute is required by the schema. However, I'm just leaving
it blank - it should be filled in the with component_manager_id for
the physical node, but that's not available at the right place in
the way that we currently pass data around.

I can't beleive the type system didn't catch this - I was pushing
a tb_plink into a list that is only suppost to take pvertex objects.
Who knows, maybe under all the templates and typedefs, they are really
the same thing. :) Now, we properly push the switch, rather than link,
onto the list of switches.

Note that this function *might* still have some memory problems, but
let's fix one thing at a time.

This commit also adds a canary to switch objects to make sure we
really do get one back from the boost get() call - it can return
garbage when you try to get() something that doesn't exist.

... to match the order seen when running with -S

When dealing with interswitch links, if the link is 'flipped',
then the interswitch path found by find_interswitch_path() is
also backwards, so we need to reverse it before returning.

If this #define is given at compile time, the RSpec version 2
annotater doesn't try to multi-hop links in any particular order.

This is a temporary hack to work around a bug in the link-reordering
code in the v2 annotator.

This should fix a bug when the neighborsize value is large, as with
large topologies or with large values for -H

When set on a physical link, this does not allow that physical link
to be used for more than one virtual link. This is mostly useful for
layer-1 links.

Currently only supported when running with -S, and on inter-switch
links.

The rest of the code should be fixed well enough for this to
work again now.

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.