New Core ROSS RNG streams; Event Time Signature Paradigm; Deterministic Tiebreaker

[nmcglo]

Re-submitted from PR #180 with better source branch

This is a big PR. Sorry, there's a lot to unpack here.

Starting with the easiest. This PR adds a new array of RNGs to ROSS LPs. These RNG streams are "Core RNGs" and access and usage of them should be reserved exclusively for the ROSS engine itself. Models should not touch these RNG streams at all. Doing so will break any determinism expected by ROSS patterns that utilize them.

Prior to now, obviously, there's nothing in ROSS that would utilize such a stream but also included in this PR is an implementation of an event tie-breaking mechanism which gives ROSS the capability of handling event ties (events that occur on the same LP at the same virtual time) in a deterministic way that is consistent between simulations, regardless of event delivery order.

Deterministic Tie-breaking can be implemented by creating a random value at the creation of an event, this value is encoded into the ROSS event struct and is utilized to break any event ties (same destination LP at same time). Because this separate RNG is only accessed by ROSS, it can be rolled back if the event becomes RC'd or cancelled. Because of
determinism, any ordering as a result of this tiebreaker will be consistent across simulation runs regardless of event delivery order or stragglers. If a regular model-accessed LP RNG was used for this purpose, the tiebreaking sequence would be subject to interference.

The deterministic tiebreaker itself is rather simple. When an event is created, a random value is generated from a ROSS core RNG stream. When that event is RC'd or cancelled, that random value is also
reversed. Because this stream is only utilized by said tiebreaking mechanism, the ordering of tiebreaking values created by the stream is deterministic across simulations. When comparing two events received by an LP at the same timestamp, the determining factor in which is processed first will be decided - deterministically - by the tiebreaker value.

While the concept itself is simple, and implementing the tiebreaker into the event struct is similarly simple, getting this
to work with the concept of GVT and rollbacks is not.

A better way to think about this tiebreaking mechanism is to think of it as making sure that there are actually no such thing as event ties. This paradigm shift means that determining "when" GVT happens is no longer a single TW_STIME value. There is now an event signature struct which contains a timestamp and a tiebreaker value. This signature is all that is necessary for determining ordering of two events in the simulation. Thus, the time of the last GVT is no longer just the single dimensional virtual timestamp, but it also includes a tiebreaker which divides events that happen at the same primary timestamp as GVT but with their own tiebreaker values which will be deterministically separated as "before GVT" and "after GVT".

Thus, rollbacks now also no longer go back to a single timestamp value in time, but to a two dimensional timestamp value consisting of the primary timestamp and an event tiebreaker.

As complex as this system is, it does have its benefits:

1. Comparing events for Splay and AVL trees to determine ordering require fewer comparisons and thus less compute time spent.
2. If primary timestamp ties are numerous in a model, rolling back of one event at said timestamp will no longer require rolling back all events with the same timestamp, only those whose tiebreaker values
   determine that they happen "after" the event that prompted the rollback.
3. Event ties are statistically impossible to force. Because the tiebreaker value is generated using its own independent RNG stream with an extremely long period, two events at the same primary timestamp ALSO generating an identical random value is nearly impossible. This also means that model developers will no longer have to generate their own small noise to add onto their event timestamps to prevent event ties, significantly improving the administrative code complexity - reducing the likelihood that a developer will forget to roll back an RNG from noise and plunge their entire model into non-determinism.

This feature has been walled off behind a CMAKE Define Variable: USE_RAND_TIEBREAKER. Set this value to ON during CMAKE ROSS configuration and all code enabling the tiebreaking value generation and the timestamp-to-time-signature paradigm shift will be switched on by pre-processor #ifdef's.

Ultimately, it may be beneficial to make this event time signature the actual primary mechanism by which the ROSS engine operates but I didn't want to make said major change in this PR. There is probably a cleaner way to implement it as well (possibly using the TW_STIME API?)

---

If this merge represents a feature addition to ROSS, the following items must be completed before the branch will be merged:

• Document the feature on the blog (See the website Contributing guide).
  Include a link to your blog post in the Pull Request.
• Builds should cleanly compile with -Wall and -Wextra.
• One or more TravisCI tests should be created (and they should pass)
• Through the TravisCI tests, coverage should increase
• Test with CODES to ensure everything continues to work