Fix #1452, Remove softsleep, as a dead store.

[thesamprice]

Describe the contribution
A clear and concise description of what the contribution is.

• Removes softsleep, as it doesnt appear to be used.

Testing performed
Steps taken to test the contribution:

2. Run through your ci pipeline

Expected behavior changes
A clear and concise description of how this contribution will change behavior and level of impact.

• Or no impact to behavior

System(s) tested on

• Hardware: [e.g. PC, SP0, MCP750]
• OS: [e.g. Ubuntu 18.04, RTEMS 4.11, VxWorks 6.9]
• Versions: [e.g. cFE 6.6, OSAL 4.2, PSP 1.3 for mcp750, any related apps or tools]

Additional context
Deleting code

Contributor Info - All information REQUIRED for consideration of pull request
Full name and company/organization/center of all contributors ("Personal" if individual work)

• If NASA Civil Servant Employee or GSFC Contractor on SES II
  • Address/email/phone and contract/task information (if applicable) must be on file

[skliper]

Worth an issue and discussion. I'd like to try and understand/document what the intent was before deleting (maybe it's future work to use it or related to another issue?)

[thnkslprpt]

Worth an issue and discussion. I'd like to try and understand/document what the intent was before deleting (maybe it's future work to use it or related to another issue?)

Looks like the functionality that used softsleep was removed back in 2019 with issue #271.

[jphickey]

This is fine. "softsleep" was an alternative timing mode that would simply call clock_nanosleep() with an interval timer value adjusted by sampling clock_gettime() with each tick. This would create a stable metronome (drift compensated) without requiring an interrupt or signal from the kernel.

This structure member was used to store the previous clock sample so the difference/time to next tick could be calculated.

As most systems do provide a facility to configure a timing interrupt or signal, the softsleep option wasn't used and the code was removed years ago, but this structure member and the call to clock_gettime() must have been overlooked.

[dzbaker]

@thesamprice CCB 20 October 2022: Approved pending resolution of conflicts.

[thesamprice]

I probably wont get to resolving these conflicts anytime soon.
Its not effecting my use cases.

[thesamprice]

I wont get to this for a while, its not impacting any of my functionality.
I spotted it a year ago and mentioned, but have some fires i'm fighting now.