SF-3081 Show draft queued immediately when job started

[RaymondLuong3]

There is a small delay between when a draft is started and when we get the draft job from the draft generation service that indicates that the build was queued. The small delay after the build is started will look like nothing happened when the user initiates a draft build and can be confusing. This PR delays closing the draft generation stepper until a queued job is retrieved from serval. A spinner progress is displayed as the user waits for the queued job.

---

This change is 

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.19%. Comparing base (6b4ba8b) to head (3ce7aa4).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2853   +/-   ##
=======================================
  Coverage   79.19%   79.19%           
=======================================
  Files         533      533           
  Lines       30953    30955    +2     
  Branches     5050     5028   -22     
=======================================
+ Hits        24514    24516    +2     
- Misses       5655     5666   +11     
+ Partials      784      773   -11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[Nateowami]

This is an improvement, but it's more of a band-aid than a fix.

Here's what it looks like in the new state that's been added:

And here's what it looks like a few seconds later:

• Description of old draft is different
• The "New draft" button is still present

I also don't see anything addressing or commenting on the related race-condition bug mentioned on the issue. It's possible it should be a separate fix, but I included it as part of the issue because they're extremely similar and can't be separated without investigating the root cause.

[RaymondLuong3]

I can investigate further into why a draft does not get started if leaving the page before the queued build returns.

[RaymondLuong3]

I found a better solution for this issue. If we delay closing the draft generation stepper until we get the initial queued job, then it will be much less confusing to users. I've made this change.
I was unable to reproduce the issue with the draft not starting when navigating away from the draft generation page. With this change, it seems less likely for a user to do that (but still possible). I think that deserves a new card if desired.

Reviewable status: 0 of 7 files reviewed, all discussions resolved

[Nateowami]

I haven't reviewed the code, but this looks a lot cleaner. Thanks for working on this @RaymondLuong3

[pmachapman]

Your code looks good - just one nit.

I was able to recreate the initial bug with a Back Translation: (up to you if you want to fix that in this PR or another PR)

1. Connect to a back translation project and set the source
2. Start a build
3. Refresh the page

The Generate Draft button will display, rather than the build progress. This is because the sf_project.translateConfig.preTranslate flag has not been set (see the checkbox in Serval Admin in screenshot below). My suggested solution is to set the preTranslate flag as on of the first actions in MachineApiService.StartPreTranslationBuildAsync()

Reviewed 7 of 7 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @RaymondLuong3)

---

src/SIL.XForge.Scripture/ClientApp/src/app/translate/draft-generation/draft-generation.component.spec.ts line 82 at r2 (raw file):

  class TestEnvironment {
    readonly testOnlineStatusService: TestOnlineStatusService;
    readonly startedOrActiveBuild$: Subject<BuildDto> = new Subject<BuildDto>();

NIT: Remove the double type declaration, i.e.

readonly startedOrActiveBuild$ = new Subject<BuildDto>();

[RaymondLuong3]

I will open a new card for this so that it can be properly tested in isolation. Thanks for the steps to reproduce the bug!

Reviewable status: 6 of 7 files reviewed, all discussions resolved (waiting on @pmachapman)

---

src/SIL.XForge.Scripture/ClientApp/src/app/translate/draft-generation/draft-generation.component.spec.ts line 82 at r2 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

NIT: Remove the double type declaration, i.e.

readonly startedOrActiveBuild$ = new Subject<BuildDto>();

Done.

[pmachapman]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @RaymondLuong3)