SF-3813 Remove reference to old onboarding form

[pmachapman]

I also added an @deprecated codedoc comment to all of the unused feature flags.

---

This change is 

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.86%. Comparing base (704cc65) to head (5d31fa1).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3947      +/-   ##
==========================================
- Coverage   80.88%   80.86%   -0.03%     
==========================================
  Files         634      633       -1     
  Lines       41019    41001      -18     
  Branches     6655     6674      +19     
==========================================
- Hits        33179    33155      -24     
+ Misses       6802     6792      -10     
- Partials     1038     1054      +16     

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

[Nateowami]

@Nateowami made 2 comments.
Reviewable status: 0 of 4 files reviewed, 2 unresolved discussions (waiting on pmachapman).

---

src/SIL.XForge.Scripture/ClientApp/e2e/workflows/onboarding-flow.ts line 42 at r1 (raw file):

  const user = new UserEmulator(page);

  await disableFeatureFlag(page, 'Show developer tools');

I suspect this line is only here because the developer tools get enabled in the process of turning the feature flag on.

So the logic was:

• turn on feature flag (implicitly turns on dev tools so it can turn a flag on)
• turn off dev tools so screenshots will be more representative

If that's the case, and I think it is, the second line is now moot.

---

src/SIL.XForge.Scripture/ClientApp/src/xforge-common/feature-flags/feature-flag.service.ts line 375 at r1 (raw file):

  /** @deprecated This feature flag is no longer used */
  readonly inAppOnboardingForm: FeatureFlag = new ServerOnlyFeatureFlag(

I've found it quite odd to see the server being indicated as the authority when the server doesn't even have a record of this feature flag. It seems like ServerOnlyFeatureFlag is implemented in such a way that if it can't find the flag it defaults to it being on? That's seems really odd to me.

The point of the StaticFeatureFlagStore was to be a hard-coded value. To me it looks like we're hard-coding it on the front-end by saying it's a back-end flag, which doesn't exist, and then just falling back to having it on by default.

[pmachapman]

@pmachapman made 2 comments and resolved 1 discussion.
Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on Nateowami).

---

src/SIL.XForge.Scripture/ClientApp/e2e/workflows/onboarding-flow.ts line 42 at r1 (raw file):

Previously, Nateowami wrote…

I suspect this line is only here because the developer tools get enabled in the process of turning the feature flag on.

So the logic was:

• turn on feature flag (implicitly turns on dev tools so it can turn a flag on)
• turn off dev tools so screenshots will be more representative

If that's the case, and I think it is, the second line is now moot.

Done. Removed. I kept the function though in case we need to use it in e2e tests later.

---

src/SIL.XForge.Scripture/ClientApp/src/xforge-common/feature-flags/feature-flag.service.ts line 375 at r1 (raw file):

Previously, Nateowami wrote…

I've found it quite odd to see the server being indicated as the authority when the server doesn't even have a record of this feature flag. It seems like ServerOnlyFeatureFlag is implemented in such a way that if it can't find the flag it defaults to it being on? That's seems really odd to me.

The point of the StaticFeatureFlagStore was to be a hard-coded value. To me it looks like we're hard-coding it on the front-end by saying it's a back-end flag, which doesn't exist, and then just falling back to having it on by default.

ServerOnlyFeatureFlag is accurate but also a misnomer. It is in a sense a feature flag that won't change unless the server tells it to change (and this only when the application starts).

We could rename it to StaticFeatureFlag (as opposed to the FeatureFlagFromStorage which is an ObservableFeatureFlag.

[Nateowami]

@Nateowami made 1 comment.
Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on pmachapman).

---

src/SIL.XForge.Scripture/ClientApp/src/xforge-common/feature-flags/feature-flag.service.ts line 375 at r1 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

ServerOnlyFeatureFlag is accurate but also a misnomer. It is in a sense a feature flag that won't change unless the server tells it to change (and this only when the application starts).

We could rename it to StaticFeatureFlag (as opposed to the FeatureFlagFromStorage which is an ObservableFeatureFlag.

StaticFeatureFlag makes a lot of sense to me.

[pmachapman]

@pmachapman made 1 comment and resolved 1 discussion.
Reviewable status: 0 of 4 files reviewed, all discussions resolved (waiting on Nateowami).

---

src/SIL.XForge.Scripture/ClientApp/src/xforge-common/feature-flags/feature-flag.service.ts line 375 at r1 (raw file):

Previously, Nateowami wrote…

StaticFeatureFlag makes a lot of sense to me.

Done.