feat: implement database vacuuming.

[keithamus]

This change attempts to resolve #2927 by introducing the ability to VACUUM the database by:

• giving atuin-server-database the vacuum method. This simply calls sqlx::query("VACUUM"). I also added a test, as we're using sqlx & sqlite this test can be executed in memory. Sadly the same cannot happen for postgres, but the test is kind of trivial.

• exposing a vacuum endpoint on the server. This handler calls vacuum. This can be useful for users who wish to manually vacuum a db, but this is not exposed via the CLI, instead...

• adding auto_vacuum_threshold option to the server configuration. auto_vacuum_threshold is > 0, then the server will increment the delete_count atomic counter, and when this counter reached the threshold it will call vacuum and reset the counter.

The default for auto_vacuum_threshold is 0 meaning "never vacuum", but users can set this to a value which will come down to their preference, guided by:

• How long they anticipate their server running for. For example setting it to a high-ish number like 1000 would probably be appropriate for a server running on a machine which has long uptimes. For self hosting for a single user, this might be a little long though, keeping in mind that if the server goes down (or the mahcine goes down) the counter will reset to 0.

• For users who really care about disk space and don't really care about latency on deletes, setting to 1 will will vacuum on every delete.

I considered adding some kind of "recommended" number but I don't think there is a good number to unilaterally recommend for this.

[ellie]

Might we be better off by enabling PRAGMA auto_vacuum = full on the server?

[keithamus]

Sounds sensible. I'm not a DB expert so I don't know what heuristics auto_vacuum uses.