ignore remote change counters on database restore if local db file exists

[Horusiath]

This PR skips process of validating local and remote change counters between local database file and remote snapshot if we found a DB file. In such case it will always call for a new snapshot.

Concerns

1. This means that every time machine is restarted, a new generation will be created - we cannot reuse them if we're going to ignore the remote counters.
2. @psarna what if during restoration process we had a non empty WAL besides db file? Can we assume that xFrames callback will happen and that we'll pass info about frames to be send to S3 before possible checkpoint?

[haaawk]

Sounds reasonable to me. Just to confirm, old generations will still be present on S3 and we will be able to use them if it turns out the local data is corrupted, right?

[psarna]

@psarna what if during restoration process we had a non empty WAL besides db file?
let's checkpoint that before we create a new generation. It's part of the boot process, so there are no writers yet and we can just checkpoint the WAL and have a proper checkpointed db to snapshot and start a new generation from

[Horusiath]

I've checked that we have this scenario covered here: https://github.com/libsql/sqld/blob/55a5c641abccf25b4176f0d47925081ffe65fdab/bottomless/src/replicator.rs#L671C31-L671C31 At the end of snapshot db request we also try to replicate WAL if it has been found.