Speed up unit testing CI by updating maxWorkers setting

[Swiddis]

Description

I did some poking around on why our tests might be so slow in CI, and discovered that by default Jest limits itself to 50% of CPU resources. GH Actions has 2 cores, so setting it manually may make our tests run considerably faster.

This is mostly just experimental to see what the difference is.

Issues Resolved

N/A

Check List

• New functionality includes testing.
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented.
  • New functionality has javadoc added
  • New functionality has user manual doc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

Merging #884 (7cbebcb) into main (6ec0967) will not change coverage.
Report is 3 commits behind head on main.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #884   +/-   ##
=======================================
  Coverage   43.72%   43.72%           
=======================================
  Files         313      313           
  Lines       18629    18629           
  Branches     4534     4534           
=======================================
  Hits         8146     8146           
  Misses       9932     9932           
  Partials      551      551           

Flag	Coverage Δ
dashboards-observability	43.72% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[Swiddis]

Results (comparing with the current run of #857):

Before:
Ubuntu: 18m  2s   Windows: 25m 14s   Mac: 21m 43s
Changed to maxWorkers=2:
Ubuntu: 11m 11s   Windows: 16m 38s   Mac: 23m 10s 
Changed to maxWorkers=100%:
Ubuntu: 12m 49s   Windows: 15m 59s   Mac: 20m 58s

It is faster, but not dramatically so, and since Mac doesn't see a speedup it won't really affect how quickly PRs get complete feedback. It might still be worth it just to have a faster result when making pushes.

Update 1: A quick check of the Mac logs shows that in both the old and new config, Mac is spending about 40 minutes of CPU time on tests. I suspect it may have already been splitting the workload, so you would expect to see no performance improvement. I'll also test with 100% to see if it happens to have 4 cores on-hand.

Update 2: 100% performs about the same for all 3, looks like Mac is just running slow and doesn't really see any speedups from this. Conclusion from before is the same, doesn't significantly change time for full CI but does give us a 5-10 minute shorter feedback loop on Unix and Windows.