Convert config service to be strict compliant

[Hinton]

Type of change

- [ ] Bug fix
- [ ] New feature development
- [x] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [ ] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

Explore how much effort it is to convert services to be strict compliant. I believe the config service should preserve the existing behaviour.

The changes are primarily to:

• Add undefined or ? to non required properties/return values.
• Replace some usages of null with undefined. (Not strictly required but it makes the handling easier.
• Add abstract keywords to abstract service.
• Rename spec to match the implementation.

Before you submit

• Please add unit tests where it makes sense to do so (encouraged but not required)
• If this change requires a documentation update - notify the documentation team
• If this change has particular deployment requirements - notify the DevOps team
• Ensure that all UI additions follow WCAG AA requirements

[codecov]

Codecov Report

Attention: Patch coverage is 50.00000% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 27.14%. Comparing base (d12953f) to head (3802d24).

Files	Patch %	Lines
...platform/services/config/default-config.service.ts	50.00%	2 Missing ⚠️
.../src/platform/abstractions/config/server-config.ts	50.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8561   +/-   ##
=======================================
  Coverage   27.14%   27.14%           
=======================================
  Files        2329     2329           
  Lines       67926    67926           
  Branches    12689    12689           
=======================================
  Hits        18438    18438           
  Misses      48095    48095           
  Partials     1393     1393           

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

[MGibson1]

Overall, the better way to achieve strict-null in state providers is to redefine key definitions such that the return state is always | undefined rather than forcing implementers to specify it.

[MGibson1]

It would be better to remove the optionality on defaultValue and force a real return.

Same with async impl

[Hinton]

I can default it to false. I tried to avoid changing the actual behaviour.

[MGibson1]

It would be better to default based on the incoming type.

[Hinton]

I disagree with this change though. I think we should postpone making this change until we refactor the feature flags to be able to enforce type checking. That will also allow us to provide a reasonable default value like false, 0, "".