Fast paths for DataTimeline modifications about time-steward

[elidupree]

Refinement: we don't need to use raw pointers or extra data for history links. If each page gets a serial number and is (for instance) 1024 history items long, then we can link to it with a usize, using the bottom 10 bits for the position within the page, and the rest of the bits for the serial number. First look up the page number in the TimeSteward, then look up the individual item in the page.

[elidupree]

We can't really do the same thing for events. Discarding history worked because history only goes up to the present time. But we create events in the future. So pages might have far-future events on them, preventing them from getting deleted.

If that can be worked around somehow, we can do the same thing for events, making EventHandle a glorified usize.

Pros:

• no need for reference counting of events (reduced time cost and memory cost)
• obsolete events can be freed while there are still links to them (reduced memory cost)
• much simpler allocation of events (reduced time cost, and probably an improvement in memory usage as well because of fragmentation)

Cons:

• dereferencing an event handle is slightly more expensive in time
• dereferencing an event handle can fail inconsistently (this would be a pro if it was guaranteed to fail for events before the forget-before time, but that won't be guaranteed, at least not without a time cost)

Seems clearly advantageous if dereferencing events isn't very common. When do we dereference events?

• In order to sort future events and know what's coming next (log n per event, but we might use something like a radix trie for that, which would remove this case)
• When an event actually comes up to be executed (assumption: no more than approximately once per event)
• When going back in history (assumption: much less than once per event)
• When client could does it explicitly (none of my example simulations have done this yet)