It's now a Tick that locks down event order. Before this change, the
event order would be locked down in the order the server sees it.
Fixes#59Fixes#61
This ensures the transaction cannot be processed on a chain
that forked before that ID. It will also provide a basis for
expiration constraints. A client may want their transaction
to expire, and the generators may want to reject transactions
that have been floating in the ether for years.
Before this change, the logger's send channel could quickly be
flooded with Tick events. Those events should only be passed to
a writer.
Also, the log_event() function no longer sends entries. That
functionality moved to the new process_events() function. This
will allow us to initialize the with the genesis block without
flooding the send channel with events the historian won't read.
Before this change, num_hashes meant the number of hashes since
the last ID, minus any hashing done on the event data. It made
no difference for Tick events, but logged Transaction events with
one less hash than actually occurred.
