Introduced back when I added a "last-hop" queue to allow prioritized
messages to go to the front of the set of msgs loggp is to receive. Haven't yet
put it in other models (simple*), so RNG bug doesn't affect there yet.

same var name used for the "sequencing" macros

doesn't support IO operations

Tired of explaining that it's not a good representation of a WAN. Instead, it's
now a simple point-to-point latency/bandwidth model.

NOTES:
- torus does not use it, as it has some routing logic preventing direct usage.
  It probably can be done, but I'll leave that for later.
- collectives in torus, dragonfly don't use it yet.

(have NO idea how the triton tests passed without this...)

Rather than model-net LPs directly sending messages to other model-net LPs, LPs
can route the intended message through the scheduler interface to be queued up
for reception by the receiver (see the diff of loggp.c). This has the benefit of
    enabling things like priority and fairness for N->1 communication patterns.
    Currently, no packetizing is supported, and I haven't yet wrote checks for
    it - beware.

Loggp is currently the only supported model. simplenet could also be supported
without much trouble, but I doubt there's any demand for it at the moment.  This
should NOT be used by the dragonfly/torus models, as they have their own routing
backend.

Torus and simplewan each have problems precluding them from the current
scheduling fix:
- simplewan - each "device" has N input/output ports. It can't simply tell the
  scheduler when they are (it is?) idle because the scheduler doesn't know which
  packets go to which ports
- torus - also has N input/output ports (two for each dimension). Also, the same
  routing "queue" (via the "next_link_available_time" var) is used for incoming
  and outgoing messages, so we can't guarantee the scheduler that we'll be
  available at time x (an incoming msg could arrive and then be routed at time
  x-1). This isn't a problem for the dragonfly network as terminals aren't
  intermediate routers. Ideally what needs to happen here is for the
  intermediate packets/chunks to be queued up in the scheduler.

- previously, packet issues were done without any consideration for device
  availability - within epsilon, preventing any meaningful scheduling
- enabled for loggp only, other networks will be incorporated shortly