Processing back_from_fork event change context's current block num,
it was not a problem when an application process events before
reaching fork event, because block num was updated during servicing each
event. The problem is when some events before fork event were removed
and the application is moving on irreversible blocks, in such situation
servicing fork event will change current blocknum regardles on which
irreversible block context is. Separated from fork processing update
contexts fork id was added.
During searching a next event to process by an application
there is a need to limit range of possible events id to max. event id
from the moment when searching was started, othweriwse there
may inconistency occure when sql-serializer will commit new events when
searching is in progress.
When hived is stopped and then started to continue syncing blocks, then
it adds artificial BACK_FROM_FORK events, which forces applications
to clean up reversible data collected just before stoping the hived.
Attached applications which are traversing range of irreversible blocks
ommited fork events, because they have only irreversible data, but
servicing of fork event not only reverts reversible data, but also
change contexts fork_id, and in consequences when the applications
reached first new reversible block, then their views did not see it
because contexts have old fork_id.
Because sometimes WAL has latency with dumping blocks to databse,
it is better to wait for a block presents instead of expecting it immediatly
after enter to live sync
Sometimes happens that HAF stucks for a long time (i.e. for some reason
indexes are rebuilt), is such situations innocent applications were
auto-detached because during waiting for new blocks 'last_active_at' was
not updated.
Previously, auto-detach would modify the current block number
upon detaching a context. This resulted in a scenario where,
after an application restart and reattachment, the same block
was processed twice.