Initialize object caches in a safer manner

[seanbudd]

Link to issue number:

none

Summary of the issue:

During NVDA initialization, the api module is used to set initial object caches.
These api functions check if an object is behind the lock screen when Windows is locked before setting the cache.
Until #14301, the api module initialised the object caches to the desktop object.
When NVDA started on the lock screen, it failed to set the desktop object due to the added security checks.
Now the object caches are initialised to the foreground window, to avoid leaking insecure information.
Unfortunately, setting those object caches causes side-effects, which may rely on uninitialized dependencies.

Description of user facing changes

None

Description of development approach

Revert to setting initial object caches to the desktop object.
Ensure security failures are not raised when initialising caches by ignoring the windows lock state.

Testing strategy:

Manual testing
Use speech, enable error sounds, and monitor the logs for errors/warnings.

• Smoke test the sign-in flow from lock, switch users, sleep, restart, log in and log out, checking the lock screen, sign-in screen, and general NVDA usage after sign in.
• Smoke test the UAC dialog
• Test the STR for security issues fixed in 2022.3.1

Known issues with pull request:

None

Change log entries:

None, fixes unreleased regression

Code Review Checklist:

• Pull Request description:
  • description is up to date
  • change log entries
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• API is compatible with existing add-ons.
• Documentation:
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• Security precautions taken.

[AppVeyorBot]

• PASS: Translation comments check.
• FAIL: Unit tests. See test results for more information.
• PASS: Lint check.
• FAIL: System tests. See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/4ae2h8gdkxai81fj/artifacts/output/nvda_snapshot_pr14333-27080,87a0aef2.exe

See test results for failed build of commit 87a0aef2eb

[feerrenrut]

It's worth noting that this couples isWindowsLocked() with NVDA initialization and each of:

api. setDesktopObject()
api.setForegroundObject()
api.setFocusObject()
api.setNavigatorObject()
api.setMouseObject()

The approach taken here allows for a smaller change, and lower risk in this PR.

Ideally, each code path that might be blocked by isWindowsLocked() is considered and explicitly allows an exception for initialization. I expect that when the api.setXXX functions are refactored to allow independent initialization without calling through to app modules etc. the new init versions of those methods will be the only place the exception (for not calling isWindowsLocked() is required.