CS-57: Fix threading for TSC and fix CI for bionic nodejs version incompatibility

[paulbourelly999]

PR Details

Description

This PR addresses to regressions in the TSC Service.
The first of which is related to launching the threads necessary for consuming a desired phase plan and making the appropriate NTCIP 1202 calls to a traffic signal controller (TSC). We use std::thread s for this and call the join() method on each instead of detach() to launch all our threads ( See sonar scanner rule and CPP Core Guidelines to see why we use join instead of detach). The std::thread::join() call blocks until the referenced thread completes execution. Due to this , all join() calls need to be at the end of their scope. Inserting a join() call before some other logic will prevent that logic from executing until the joined thread completes execution, which for many of these threads will only happen when the service shuts down.
As part of some MMITSS development this join was moved into the incorrect location causing the control_tsc_phases thread never to be created. Moving all the join() calls to the end of the start method allows all threads to run and no logic to be blocked by thread execution completion.

The second more benign regression was that we changed the SNMP COMMAND LOGGER to take it's name from a constant. In doing so, the name changes and calls to retrieve this logger did not use the correct name. This was also fixed in this PR

The final change is exclusively to fix issues with the CI process related to bionic (ubuntu distribution) incompatibility with many github actions due to its incompatibility with newer versions of nodejs. This environment variable allow github runners to use deprecated versions of nodesJS. Eventually we plan to remove bionic from CARMA Streets.

Related GitHub Issue

Related Jira Key

CS-57

Motivation and Context

Hot fix for carma-system-4.5.0 for TSC Service. Fixing functionality to control phases given a desired phase plan.

How Has This Been Tested?

Tested in CDASim deployment

Types of changes

• Defect fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that cause existing functionality to change)

Checklist:

• I have added any new packages to the sonar-scanner.properties file
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[SaikrishnaBairamoni]

PR looks good to me. As long as we have comments and are tracking them, we can update it accordingly.