Update fingerprint if plan is still valid

We have three guards in place for replanning:

1. How much time has passed since the query was planned?
2. How many transactions have been committed since the query was planned?
3. How much has the statistics changed since the query was planned?

These guards are ordered the way they are since it is assumed that the later guards are more expensive than the former guards. Going to the store for the current transaction ID is more expensive than looking at the current time, and going to the store for several statistical values is more expensive than just getting a single transaction id.

This has a problem in that after a guard has first failed, it will continue to fail even if the later guards still keep the query alive. Say that the database is very read heavy, so after the default query TTL of 1 second has passed, guard (1) will always say that the query needs to be re-planned. This means that we will always go to disk to read the transaction ID, making each execution of the query more expensive.

This PR solves this by updating the guards that say "replan" if a later guard says not to replan. I.e. we should update the timestamp for a query if we find that we have not seen that many transactions.
That's true, it would read nicer but it is a bit cumbersome to mix it with the update side effect. Indeed, you don't know if you need to update the fingerprint until the last guard has been evaluated.