repro: pull all missing files

[daavoo]

• reproduce: Update pull to also pull run cache.
• reproduce: Update pull to also pull changed stages.

Closes #4742

Point 1 in #9375 (comment)

[daavoo]

@dberenbaum ping

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.01 🎉

Comparison is base (c75a558) 91.59% compared to head (67ff3e1) 91.60%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9395      +/-   ##
==========================================
+ Coverage   91.59%   91.60%   +0.01%     
==========================================
  Files         487      487              
  Lines       37822    37855      +33     
  Branches     5440     5443       +3     
==========================================
+ Hits        34642    34677      +35     
+ Misses       2623     2622       -1     
+ Partials      557      556       -1     

Impacted Files	Coverage Δ
dvc/repo/reproduce.py	97.69% <100.00%> (+0.11%)	⬆️
tests/func/test_repro_multistage.py	100.00% <100.00%> (ø)
tests/func/test_run_cache.py	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[dberenbaum]

Haven't tested, but assuming it's the same as #9375, LGTM

[efiop]

This might take awhile, but I guess this is acceptable with --pull. But still hope to finally get to converting run-cache to dvc-objects to that this operation could be efficient.

[skshetry]

I am against this PR as I have written here.
#9375 (comment)

1. pull checks out outputs. We support running repro in parallel. When we run the command, we unlock the lock, so that users can run repro separately if they like. But we still rwlock the outputs, preventing from outputs and dependencies to change at the same time. This does not do that, so there's a chance that this will change workspace for the output that the still-running repro is trying to generate.
2. It uses a high-level API, that is not meant for this use and does that in a loop. It'll make it harder for us to change UI for example. It should go through a simpler interface. This is my bigger concern.

[daavoo]

I am against this PR as I have written here. #9375 (comment)

1. pull checks out outputs. We support running repro in parallel. When we run the command, we unlock the lock, so that users can run repro separately if they like. But we still rwlock the outputs, preventing from outputs and dependencies to change at the same time. This does not do that, so there's a chance that this will change workspace for the output that the still-running repro is trying to generate.

So, if I move the pull to inside stage.reproduce, this would rwlock as expected, right?

2. It uses a high-level API, that is not meant for this use and does that in a loop. It'll make it harder for us to change UI for example. It should go through a simpler interface. This is my bigger concern.

Do you have any ideas for a simpler interface? Putting it inside the stage and using cloud.pull would be better?

[daavoo]

We support running repro in parallel.

Side question. Do we have any tests for this?