Previously, the attempt was made to enable only those `tokio` features
that are actually used. However, due to default-features still being
enabled and `tauri` using the `full` feature, for most intents and purposes
that wasn't effective.
Now default features are disabled, and `full` isn't used anymore, forcing
all crates to mention the exact features they need.
Note that `tracing` is missing here, as it wasn't effective previously
without the `--cfg tokio_unstable` option also being specified as rustflag.
Previous implementation of `joined` would fail this test:
```
st virtual_branches::r#virtual::tests::joined_test ... FAILED
at crates/gitbutler-core/src/virtual_branches/virtual.rs:4139:9:
assertion failed: joined(2, 3, 1, 4)
```
The `pure` functions were from a time where a `Handler` couldn't be instantiated
in full for tests, but that is not the case anymore, so there isn't any use
for the added complexity.
Previously it would watch every registered project, which could incur more work
on all parts of the application than necessary.
Now UI sends an event that indicates which project is active, allowing the
watch to be setup in that very moment. It's worth noting that the previously
watched project is automatically deregistered.
Previously, each file change both in `.git` as well as in the worktree would
cause a complete recomputation. This computation included opening a git
repository at least once (probaby more often), to make an 'is-ignored' check.
The latter is very expensive in `git2` and gets more expensive the more
files there are.
Now the repository is opened when needed, and we re-use it for all applicable
file paths.
The idea is that we don't parallelize over a channel anymore, but
instead just process filesystem events, one at a time.
This would allow each handler to become a function that gets its
state passed, and makes all the necessary calls verbatim, which
in turn makes it easy to follow what's happening.
If anything becomes to slow due to the serialization of event processing,
selective parallelization can be re-added.
Sub-Handlers are objects, and with that comes a lot of complexity.
However, there seems to be on need for it at all, and a first
steps is to turn these into methods to truly understand
what's going on.