Fix Issues with Rebuilding the PatientLastChange Index

[alexanderkiel]

The PatientLastChange index contains all changes to resources in the compartment of a particular Patient on reverse chronological order. Using the PatientLastChange index it's possible to detect the t of the last change in a Patient compartment.

While migrating from a version of Blaze before 0.27, the PatientLastChange index is rebuild by just traversing all transactions from the transaction log again and create the same index entries as a normal transaction would have done. This is an idea from event sourcing and it works unless one has way too many transactions.

For the PatientLastChange index, it's not important to know how far away in the past the last change on a Patient was, unless old CQL Bloom filter entries exist. So for a newly migrated system, it's actually off to have the current t for all Patients in the index. So instead of going though all transactions again, just using the t at time of index build is ok.