JGit should run its bookkeeping in the background

[hubertp]

Pull Request Description

JGit ops generally run fast (as in a few milliseconds) except for the first commit. The initialization + first commit was taking at least 3.5 seconds constistenly, but only in the first test case. Now, this led to frequent timeouts down the chain when the request was expected to finish fast.
The bookkeeping involved some timestamping and other expensive calls in order to calculate clock drift. The default appears to be to run it in a blocking mode, hence adding at least 3 seconds to the first command call.

Setting the job to run in the background makes the cost of the repo initialization acceptable (~300 milliseconds on a cold JVM). The other commands are unaffected and take < 10 milliseconds.

Important Notes

Added a test to ensure that we don't introduce the regression. Marked it as potentially flaky because it uses timestamps and it is therefore prone to random system hiccups.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  Java,
  and
  Rust
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH
    ./run ide build and ./run ide watch.

[hubertp]

As per (very hidden) documentation:

whether FileStore attributes should be determined asynchronously. If false access to cached attributes may block for some seconds for the first call per FileStore

I just wish they set it to true by default 🤦

[JaroslavTulach]

Doing "something sooner" is a classical way to improve UI responsiveness. Your change just uses FileStoreAttributes.setBackground(true), but I think we should do more. It is clear the JGit integration is going to be needed once user starts editing the program. We should pre-initialize the JGit infrastructure during startup.

In NetBeans (I know, I know) we tried to open and show main window as soon as possible. That gives the user early response, allow him to explore the IDE and choose what to do next. However that moment isn't "end of startup" - behind the scene we slowly (with low priority) continue initializing systems the user will likely need. For example we may perform a dry run of a Java parser, pre-load all menu items, initialize version control system support.

References:

• @OnStart - https://bits.netbeans.org/16/javadoc/org-openide-modules/org/openide/modules/OnStart.html
• @OnShowing - https://bits.netbeans.org/16/javadoc/org-openide-windows/org/openide/windows/OnShowing.html
• @OnStop - https://bits.netbeans.org/16/javadoc/org-openide-modules/org/openide/modules/OnStop.html

I believe we should have something similar. A set of warm up tasks that get triggered by Akka as soon as the startup is "finished" (e.g. nodes are colored) and initialize JGit and its repository for now.

[hubertp]

Doing "something sooner" is a classical way to improve UI responsiveness. Your change just uses FileStoreAttributes.setBackground(true), but I think we should do more. It is clear the JGit integration is going to be needed once user starts editing the program. We should pre-initialize the JGit infrastructure during startup.

Not necessarily. Files are obviously always saved periodically, independently of recording the history of the project. So user doesn't have to use ctrl+s.
Having said that, I agree that we could delay some of the initialization and there should be a pattern to do this across different micro-services that combine language-server.

I would still ask to get this one in as it currently interferes when normal startup execution expectations. At the same time a bigger overhaul of startup sequence is being planned, obviously.