Expire stale bobstate rows eventually

[link2xt]

This is a follow-up to #6534

Currently it is not a problem that QR codes scanning process may get stuck when Alice never replies, because there is always at most one row in bobstate table and next time bob scans a QR code, all previous processes are aborted.

With #6534 the table can theoretically become large if Bob scans thousands of QR codes from Alice's that never go online. I don't want to do anything about this in #6534 to avoid adding migration and fixing it is not urgent because this is unlikely to become noticeably slow in real usecases.

Still, I think we need a migration with a properly designed table that stores auth codes and Alice fingerprints for outstanding securejoin processes when Bob scans a QR code and does not have Alice's key yet. The table should also probably have a flag for whether the process is a group join or contact request, maybe chat ID and a timestamp of when vc-request or vg-request was generated. If the process is outdated by something like 30 days or timestamp is invalid (is in the future), the row should be dismissed.

Old bobstate table should not be deleted for compatibility, but can be cleared once during migration.

[link2xt]

A simple way without too much work would be to remove bob states that have row ID less than the just assigned/highest row ID by 100 or so, so all bob states are deleted eventually without the need to rely on clocks. No need for migration.

[r10s]

if there is something easy to do like the last suggestion, that'd be great!

otherwise, doing risky migration and refactoring with option to introduce bugs, idk

the table can theoretically become large if Bob scans thousands of QR codes from Alice's that never go online.

even then, an average animated sticker is probably larger than the table :)

in any case, there is no hurry :)