Add `--poll-watcher` flag.

[aronsky]

This enables the use of the old, poll-based watcher. For cases where thewatchfiles library (more likely, the underlying Notify library) isn't working correctly. See relevant issue #1849.

This small change adds support for using the old watcher based on polling the filesystem, instead of the new, watchfiles-based watcher. This is relevant for people (like me), for whom the new watcher doesn't work as expected. The support is via a simple command-line flag (--poll-watcher), which, when present, is propagated to the constructor of FavaLedger, where the decision to use either the old Watcher or the new WatchfilesWatcher is made based on that flag's value.

[aronsky]

More info: seems like it is, indeed, an issue with the Notify library that's used by watchfiles: see here: https://github.com/notify-rs/notify/issues/384#issuecomment-1030934574

[yagebu]

I guess this is not something we could automatically determine and switch to the polling watcher if we know watchfiles won't work on that filesystem?

There's some linter complaints the pre-commit reports, could you address those?

[aronsky]

Sure. The linter complains are mainly due to my attempt to make my changes as limited as possible, without delving into redesigning certain interfaces. Namely:

• The main function now receives an additional argument regarding the watcher type, and this puts it over the edge of acceptable argument count (10 instead of 9)
• To make sure that the watchfiles-based watcher is used by default, the boolean argument that enables the poll watcher is set to False by default, which seems to upset the linter

Is it OK to simply silence those warnings at those spots, or do you want me to refactor the code to avoid them?

And regarding automatic detection - unfortunately, I don't see such an option. The thing is, even if we detect the filesystem type on which the data resides (and let's assume we have an exhaustive list of filesystems that are problematic, even though that's not the case right now) - it doesn't necessarily mean there will be a problem. My case is a perfect example. I'm using NFS - but as long as it's a single NFS mount by the host, and multiple containers access it simultaneously, watchfiles works fine. The problem only appears when the containers are on different hosts, each of them mounting the filesystem separately. I don't see any way to detect this logically, let alone programmatically, without explicit user configuration (which this flag essentially is).