Consider implementing a common task library

[skliper]

Is your feature request related to a problem? Please describe.
There's things we code over and over again, and where we don't follow standard patterns we probably should.

Describe the solution you'd like
Create a common set of utilities for a task (aka a task library) that the core services could also use.

Candidates:

• CFE_Task_VerifyCmdLength(MsgPtr, ExpectedLength, ErrorEventId, ErrorCounter)
  • Could also pass in MsgId and FcnCode so they don't need to be looked up twice? See Pass message ID and function code into verify command length functions #1426
• CFE_Task_ResetAllCounters - see Put common and local counters in structures to simplify reset all counters command handling #1427
• CFE_Task_GetAppTaskName - see Define a const global for OS_MAX_API_NAME * 2 and use it #1457 for use in API reporting to provide consistent information
• CFE_Task_FormFullName - see Document/implement naming pattern for created elements #1412 if a common formation pattern is implemented (vs just naming pattern)
• Generic double-linked list support

Describe alternatives you've considered
Leave as-is.

Additional context
Observed when implementing #777, duplicated code is all over for a few of the standard task elements.

Requester Info
Jacob Hageman - NASA/GSFC

[jphickey]

Hate to bring it up again, but the generic method of validating commands and also dispatching them is implemented in the EDS stuff, i.e. at https://github.com/jphickey/cfe-eds-framework.

Don't even need to use that implementation, but no matter what tech is chosen, the basic fundamental concept is true: in order to implement generic/consistent code to handle messages, the messages themselves first need to be defined in a generic/consistent/implemementation-agnostic manner to support that.

Once we can settle on a way to define our CMD/TLM interfaces consistently and unambiguously (i.e. not subject to platform-dependent behavior) then a lot of great things like this become possible.