FileWatcher should expose more awatch configuration options

[llucax]

What's needed?

We need to have more flexibility to configure a FileWatcher. At the moment all watching is recursive and there is no way to set own filter and other options that are very useful to have.

Proposed solution

I see mainly 2 options that we might need to explore in more depth:

1. Making FileWatcher just a glue to use awatch with channels

This means, we just take a awatch instance in the FileWatcher configuration and we also use awatch's own event types, etc. This allows for full flexibility and zero(ish) maintenance cost for updating to new versions of awatch that could provide even more options.

The downside is stopping can't be taken care of by the FileWatcher, the users will have to provide an event themselves to stop, if they need to stop the receiver. Or maybe we can just use Task.cancel() to stop it.

2. Making FileWatcher expose more awatch options in the __init__

This means that we take in the __init__ an option to pass watch_filter, debounce, recursive and other options that will be just forwarded to awatch.

The downside is we always need to update if awatch if more features are added, and we need to create/maintain wrappers for other awatch types if we want to make the implementation hidden.

---

Since we are coupling FileWatcher with awatch anyways, and using a file watcher is not something that needs to be done very often (it is still a lowish-level construct) and has many things to consider, I lean more towards using the first approach.

Use cases

The main use case for now is the ConfigManagingActor in the SDK.

With the current FileWatcher implementation, the config manager needs to watch for a whole directory recursively just to watch for one individual file, and do the filtering manually, which is not ideal (and was difficult to understand what was going on).

Alternatives and workarounds

Use awatch directly or do some of the work manually.

Additional context

We are considering changing the underlying library, so we should have this in mind before addressing this issue:

• Filewatcher is not reporting events in CIFS mounts #256