Fix #1458, Moves OS_strnlen to public API and adds static analysis co… …mments

[chillfig]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution

• Fixes Static analysis issues JSC 2.1 #1458, Adds a disposition to a line of code in question from static analysis stating why it's safe to keep as-is.

Testing performed
Manual inspection

Expected behavior changes
N/A

System(s) tested on
N/A

Additional context
N/A

Third party code
N/A

Contributor Info - All information REQUIRED for consideration of pull request
Justin Figueroa, Vantage Systems

[chillfig]

CCB 06/13/2024: Change "Overflow is unlikely..." to "This is not considered a concern because...etc"
Also verify 29.23 years. Probably 29,230 years

[jphickey]

Definitely some mixed feelings about this. I thought we had concurred that because an overflow would only occur if the interval was over 29000 years, that it was OK as-is?

Seems like we are just shifting risk here -- although the tool might no longer complain about this, we haven't made the code any more correct. That is, if you pass in an interval that is beyond the representable range, then returning INT64_MAX is not more (or less) correct than returning some unspecified/platform-defined value. Both results would be equally incorrect.

In order to justify this change, all callers of this API would have to check for the INT64_MAX result, and (theoretically?) take some alternate action. But that is not feasible - all these tests are not free, they take time and CPU power and increase the code size and they need to be unit-tested and functional-tested and increase our future maintenance load. All for something that only occurs in the highly unlikely event that a user needs to represent a time interval greater than 29000 years, and probably won't be handled correctly anyway?

In summary - I prefer the previous approach of simply documenting the limits of what OS_time_t can represent, and instructions on how to adjust this (note that the user can change the time tick to represent a larger range or better precision, whatever is more important)