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 commit 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.
Make sure to start the standalone page cache
Merge pull request #3579 from chrisvest/2.2-fix-standalone-pagecache

Make sure to start the standalone page cache
Introducing TripletQueryGraphCardinalityModel
Draft of VarLengthTripletCardinalityEstimator
Tagging for version 2.2.0-M01
Back to development version.
Merge pull request #3582 from pontusmelke/new-card-estimates

Introducing TripletQueryGraphCardinalityModel
Merge pull request #3549 from davidegrohmann/2.2-update-fingerprints

Update fingerprint if plan is still valid
Unignore varlength tests
Refactoring of how logical plans for expanding into an existing identifier is handled