OPT: maintain cache of discovered subdatasets in the loop of annotate_paths

[yarikoptic]

Otherwise there is a rediscovery of subdatasets for EVERY path provided to annotate_paths even when they all belong to the same parent dataset.

Closes: #3567

TODOs:

• verify that nothing is broken at least according to the tests. As is mentioned in the code comment, because of its "generator" nature, if annotate_path is called from within some loop altering the list of submodules, cache could get invalidated. If there is such a usage case we should probably add some kind of sensing of mtime for .gitmodules of the parent or add an explicit argument to not retain this cache, but then things will get slow again whenever not needed
• see and report if any notable effect on benchmarks
• verify that it helps in a real use case which "inspired" this fix
• (not here) we really should add a benchmark suite operating on a set of paths within a bigger dataset across a variety of commands

[yarikoptic]

benchmarks on travis show no significant effect of any kind and all suggest a bit of slowness... kheh kheh ;-)

       before           after         ratio
     [c411d6a2]       [58c23cd8]
     <bm/merge-target>       <bm/pr>   
       1.25±0.01s       1.26±0.02s     1.00  api.supers.time_createadd
       1.22±0.01s       1.24±0.01s     1.02  api.supers.time_createadd_to_dataset
       3.32±0.04s       3.51±0.06s     1.06  api.supers.time_installr
          136±1ms          148±8ms     1.09  api.supers.time_ls
       1.23±0.01s       1.28±0.06s     1.04  api.supers.time_ls_recursive
       1.34±0.02s       1.40±0.02s     1.04  api.supers.time_ls_recursive_long_all
       2.01±0.02s       2.06±0.01s     1.03  api.supers.time_remove
          398±4ms          412±3ms     1.03  api.testds.time_create_test_dataset1
       2.78±0.03s       2.95±0.03s     1.06  api.testds.time_create_test_dataset2x2
      2.04±0.03ms      2.13±0.03ms     1.05  core.runner.time_echo
      2.84±0.05ms      2.94±0.02ms     1.04  core.runner.time_echo_gitrunner
         655±10ms          688±3ms     1.05  core.startup.time_help_np
        156±0.8ms          160±1ms     1.02  core.startup.time_import
          595±4ms        621±0.9ms     1.04  core.startup.time_import_api

[codecov]

Codecov Report

Merging #3570 into 0.11.x will increase coverage by 1.09%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           0.11.x    #3570      +/-   ##
==========================================
+ Coverage   80.25%   81.35%   +1.09%     
==========================================
  Files         255      255              
  Lines       33639    33648       +9     
==========================================
+ Hits        26997    27373     +376     
+ Misses       6642     6275     -367

Impacted Files	Coverage Δ
datalad/interface/annotate_paths.py	84.9% <100%> (+0.23%)	⬆️
datalad/interface/tests/test_annotate_paths.py	100% <100%> (ø)	⬆️
datalad/utils.py	64.51% <0%> (+0.64%)	⬆️
datalad/distribution/dataset.py	91.89% <0%> (+0.9%)	⬆️
datalad/support/annexrepo.py	58.59% <0%> (+0.95%)	⬆️
datalad/log.py	66.82% <0%> (+0.96%)	⬆️
datalad/distribution/utils.py	85.56% <0%> (+1.03%)	⬆️
datalad/support/gitrepo.py	69.17% <0%> (+1.04%)	⬆️
datalad/interface/run_procedure.py	87.97% <0%> (+1.26%)	⬆️
datalad/distribution/remove.py	73.22% <0%> (+1.57%)	⬆️
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c411d6a...af9c5a9. Read the comment docs.

[yarikoptic]

real life use case,

• 382,940 files (via git ls-tree -r) in the repo with 249,691 local annex keys
• 1,830 *feat sub directories pointing to 368,292 symlinks (annexed) and 12,810 regular files (in git)
• .git/objects is quite sizeable -- 59,322 MB (may be I should git gc after the last datalad save run)
• no sub-modules (but this repo is a 3rd level submodule)
• all data is already here (and didn't go anywhere ;-))

here is timings with eyeball averaging 3 runs:

• pure git annex get -- 3m30s
• pure 'git' '-c' 'annex.merge-annex-branches=false' 'annex' 'find' '--json' '--not' '--in' 'here' '--' which we use in datalad get to see what we actually need to get (to get idea on total size before running annex get) -- 11m43s (I guess we should check with @joeyh on how to get a more performant querying to get closer to get performance)
• patched (this PR) datalad get -- 11m48s ( so we are bound by annex find above)
• master datalad get -- 13m13s (so not that bad, but >10% time wasted)

[yarikoptic]

so, checked with @joeyh, and with using . instead of here we would get boost

• pure 'git' '-c' 'annex.merge-annex-branches=false' 'annex' 'find' '--json' '--not' '--in' '.' '--' 4m

PR #3574 will introduce that change.

[yarikoptic]

ok, since there is a boost, and no side-effects were detected so far, merging