Remote clock throws an error if time system is set before remote clock object resolved

[akhenry]

Summary

When initializing Open MCT the time system tends to be set synchronously. The remote clock registers a time system change listener that assumes that the remote clock object has been resolved, but this resolution happens asynchronously, resulting in an error.

Expected vs Current Behavior

Registering the time system event handler handler should be deferred until after the remote clock object has been resolved.

Steps to Reproduce

1. Install the remote clock plugin (or use a system where it's already installed)

        openmct.install(openmct.plugins.RemoteClock(/* some object identifier */));

3. Configure the time conductor so that the remote clock is the default

openmct.install(openmct.plugins.Conductor({
    menuOptions: [
        {
            name: "Remote",
            timeSystem: 'utc',
            clock: 'remote-clock',
            clockOffsets: {
                start: - FIFTEEN_MINUTES,
                end: FIFTEEN_SECONDS
            }
        },
        {
            name: "Realtime",
            timeSystem: 'utc',
            clock: 'local',
            clockOffsets: {
                start: - FIFTEEN_MINUTES,
                end: FIFTEEN_SECONDS
            }
        },
        {
            name: "Fixed",
            timeSystem: 'utc',
            bounds: {
                start: Date.now() - FIFTEEN_MINUTES,
                end: Date.now() + FIFTEEN_SECONDS
            }
        }
    ]
}));

4. Load Open MCT
5. Observe that it fails to load and an error is shown in the JavaScript console

Environment

• Open MCT Version: 2.1.4
• Deployment Type: viper local proxy

Impact Check List

• Data loss or misrepresented data?
• Regression? Did this used to work or has it always been broken?
• Is there a workaround available?
• Does this impact a critical component?
• Is this just a visual bug with no functional impact?
• Does this block the execution of e2e tests?
• Does this have an impact on Performance?

Additional Information

[michaelrogers]

Fix verified during testathon on 12/28/2022 locally against release/2.1.5.