Filesystem monitoring and reactive updates

[kirillt]

Ideally, we should react to changes in filesystem.

E.g. if some path P maps to id A, after an external app modified P it needs to be updated to id B.
This change also must be propagated to the tags storage since id changed.

But there are some unclear moments like if an external app, in fact, moved original file untouched to another path S and put new content to the original path P. In this case, id A is still in our collection, it just was moved from P to S, so we shouldn't change tags storage regarding A but only bind A to new path S in the resources index and bind P to new resource B.

There might be other corner cases. This feature requires to be discussed before approaching.

[kirillt]

In simple case when A is replaced with B by path P (it can be newer version of semantically same resource or completely irrelevant new resource) we can default to porting A's tags to B and highlighting this resource in resources screen, so user would notice some resources have automatic tags and she could check if tags on those resources are correct.

[kirillt]

Background filesystem monitoring should have on/off switch and also respect battery-saving settings (turn off when battery saving mode is enabled).

[kirillt]

When filesystem monitoring would be useful:

1. When resources grid is open and something is writing externally into the folder.
   This scenario affects only collection of unlabeled resources, because external entity can't create a resource with known id which already has some tags on it. If the change is modification of existing resource, it will have new id and hence will lose tags. We might also want to catch that some resource disappeared, especially from active query.

2. When resources grid isn't opened, to catch updates in all folders and save time later during opening a folder.

[kirillt]

Related issues:

• Background indexing #23
• Indexing service arklib-android#77