Submodule status: Throttle instead of drop frequent updates

[gerhardol]

I believe this is ready, but did not plan to include it in 3.4
Submitting now for discussion of #8049

Proposed changes

SubmoduleStatusProvider will not update the status more often than every 15th second to limit load.
This was added before the status update was fully async and before updates were pruned (latest change in #8116).
The status should not be noticable (at least comparable to git-status, that can take a long time in big repos with many submodules).

The update limitation remains with this PR, but instead of dropping frequent updates, the handling is throttled to update no more often than every 15th second.
The handling has also been simplified.

A change to specific mention is that previously, if not the top module was selected, the complete structure including the current submodule was updated. The current submodule was then updated a second time. (There was a comment that the update not triggered by git-status would skip this, but that was incorrect.)
This will maybe be noticeable on a deep tree where a module below submodule is updated. (but very minor effect)

Test methodology

Tests exists, a test is disabled for the same reason as before.
Can maybe be improved.

---

✒️ I contribute this code under The Developer Certificate of Origin.

[codecov]

Codecov Report

Merging #8119 into master will increase coverage by 0.26%.
The diff coverage is 81.94%.

@@            Coverage Diff             @@
##           master    #8119      +/-   ##
==========================================
+ Coverage   49.53%   49.80%   +0.26%     
==========================================
  Files         852      845       -7     
  Lines       61296    61459     +163     
  Branches    11016    11066      +50     
==========================================
+ Hits        30364    30607     +243     
+ Misses      28669    28545     -124     
- Partials     2263     2307      +44     

Flag	Coverage Δ
#production	37.41% <81.60%> (+0.08%)	⬆️
#tests	94.38% <82.00%> (-0.46%)	⬇️

[gerhardol]

Squashed and rebased https://github.com/RussKie/gitextensions/tree/fix_8077 on master, rebased this on that commit and fixed the commented out tests, added a few lines more
This was a problem with the datastructures

The bug in the application is not too severe. The status for submodules if not the top project was checked out was incorrect. So the problem requires at least three levels of submodules.

The drop down looked like this:

With the correction, it looks like the following (sidepanel is correct)

[mstv]

LGTM, needs another rebase when #8049 is merged.

[gerhardol]

The current implementation can be further simplified, no need to separate topmodule and submodule structure update

I will adjust some details

[gerhardol]

I submitted this to support #8049 in a safe way, but it has maybe grown too big for 3.4
I would like to add some more test cases for changing revisions as well (could be done later too).
I may submit an alternative with a few line changes for 3.4 instead: gerhardol@df91842

[gerhardol]

Testcases added, also checking AllSubmodules/OurSubmodules (what failed in the old testcases)
I added 300 lines of testcases, now many more but not all usages are covered. So it is still not a safenet. (Also before reviews, I am blind for issues myself now.)
Added some tests for the actual working, even if it is incomplete. For instance, if not a top module is checked out, then git-status run on the submodule and can determine that the top module is dirty. However, clearing the dirty file cannot determine that the top module is no longer dirty.

Edit: ChangedFiles does not report the expected number of changes in Appveyor, cannot see why now...

[mstv]

ChangedFiles does not report the expected number of changes in Appveyor

Without having looked at the code, it might help to add
await AsyncTestHelper.JoinPendingOperationsAsync(AsyncTestHelper.UnexpectedTimeout);
and forceUpdate: true.

[gerhardol]

Split tests and added a few more. Six tests fails on AppVeyor though. It is consistent behavior though, no evident race condition.
I check what Git options Appveyor used, nothing strange (and GE should override user settings anyway if needed.)
Will squash this (it is test cases that has changed since the review).

@mstv any more hints to why the tests fail?
Anything specific to be done so the testcases are not cleaned up and access with RDP?

[mstv]

Six tests fails on AppVeyor though.

I have not found a regarding failed AppVeyor run.

Will squash.

OK for me.

[mstv]

Printf debugging still is not the worst idea.
You could attach the debugger to the test runner.
(IIRC, the AppVeyor VM has only one cpu core with hyperthreading.)

[gerhardol]

Eventually fixed the problem, same problem as #7861: AppVeyor does not set an email address which causes commit to fail.
The testcases sets email addresses in the local config but when adding a module as a submodule, the local config is not copied.
I intend to squash the two first commits.

[mstv]

Thank you

[gerhardol]

One more corner case, with another test case

[gerhardol]

@msftbot merge in 24 hours

[ghost]

Hello @gerhardol!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I won't merge this pull request until after the UTC date Tue, 09 Jun 2020 05:02:25 GMT, which is in 1 day

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".