never delete files, but move to a recycling bin of sorts

[digitalsignalperson]

I'm trying this out for my setup:
digitalsignalperson@ce3922f

     fname = os.path.join (self.md, fname)
+    fname_new = os.path.join (self.wd, 'deleted', ffname)

     if not self.dry_run:
       if nmsg is not None:
-        db.remove(fname)
-      os.unlink (fname)
-
+        nmsg.tags.add ('deleted')
+      Path(fname_new).parent.mkdir(parents=True, exist_ok=True)
+      os.rename(fname, fname_new)
       self.files.remove (ffname)
       self.gids.pop (gid)

When the gmail recycling bin is cleared, gmi pull will move the deleted files from {account}/mail/cur/{filename} to {account}/deleted/cur/{filename}, which is outside of what is detected by lieer, but still kept in the notmuch database, and with an additional deleted tag. A notmuch new is still required after pull for notmuch to give something like No new mail. Detected 2 file renames., otherwise the next gmi push will complain with remote: could not find remote message: for these moved files. I couldn't figure out if there is an equivalent to notmuch new with the python bindings, or if there is another method in the python api to change a file's path.

This is a little different from --no-remove-local-messages, because I actually want to keep everything in sync with remote, but want insurance against accidental deletions or messages going poof on gmail side somehow. So this acts as an archive or recycling bin of sorts that I can either ignore, or go review and clear out periodically.

Let me know if some form of this would be suitable for a PR or have any thoughts

[gauteh]

I think this should be configurable. You have to look in the notmuch api for how to add and remove the file from the message, or possibly even remove and re-add the message to the database. The database should be consistent after a gmi run.