Optimize edge lookup and iteration without undue memory usage increase

[milroy]

Flux-sched builds and mutates adjacency_list graphs, requiring many edge lookups and iterations. We need to consider how to optimize such operations without an excessive increase in memory footprint.

resource_graph_t currently uses vecS as its OutEdgeList type. While Boost documentation states that vecS uses the least memory "In the order of least space to most space, the selectors are vecS, slistS, listS, and setS."

it also mentions that edge lookups with vecS (Sequence) type edges are potentially costly:

The time complexity for this operation [edge lookup] is O(E/V) when the OutEdgeList type is a Sequence and it is O(log(E/V)) when the OutEdgeList type is an AssociativeContainer.

I have tested substituting hash_setS and setS for vecS as the adjacency_list OutEdgeList type to improve edge lookup performance in the forthcoming subgraph attachment (issue #511). Flux-sched builds successfully with both, but many (~60) Travis tests fail when using hash_setS. The failures are due, at least in part, to the unordered edge iteration that results from using the hash_setS type.

Flux-sched's DFU code explores out_edges in particular subsystems, e.g.:

flux-sched/resource/traversers/dfu_impl.cpp

Line 353 in adea512

if (!in_subsystem (*ei, subsystem) || stop_explore (*ei, subsystem))

which could benefit from restricting iteration "only though those outedges that belong to a particular subsystem" (quoting @dongahn ).

It may be possible to meet both of these objectives by choosing the optimal OutEdgeList type, and modifying edge descriptors, add_edge(), out_edges(), and out_edge_iterator.

[dongahn]

This is good to have but not actionable for now. We can reopen this when we need this optimization.