SB private/internal data structure being written to telemetry dump file

[jphickey]

Describe the bug
The CFE_SB_PipeD_t structure is defined within cfe_sb_priv.h and is internally used to manage the pipe state.

But as part of the "Send Pipe Info" command this structure is also directly written to a data dump file - making it effectively into telemetry data.

Expected behavior
Code should clearly delineate what is telemetry data intended to be consumed by the ground or other systems, and what is internal data that only resides in local memory.

In particular, the CFE_SB_PipeD_t also contains pointers, so the dump file resulting from a Send Pipe Info command will contain these internal memory address (meaningless outside the current CPU) and it will change size depending on whether it is running on a 32-bit or 64-bit CPU.

System observed on:
Ubuntu 20.04

Additional context
Whether data is sent directly in a telemetry message in real time or dumped to a file and transferred to the ground system in a deferred fashion, it is all basically telemetry data and the structures used in these data dump files should be defined in consistent (i.e. non platform dependent) terms so the tools on the ground can actually parse the file (or message).

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

My suggestion/recommendation is to make this more like what ES does with its AppInfo/TaskInfo structures. Instead of directly writing the global data records i.e. CFE_ES_AppRecord_t / CFE_ES_TaskInfo_t, it defines a separate CFE_ES_AppInfo_t and CFE_ES_TaskInfo_t which are used for data dump and telemetry packets. These have mostly the same information but the latter is "sanitized" to make it into a consistent binary format.

[skliper]

This would be a good time to fix. Concur w/ recommendation.

[skliper]

Consider along with #995 and possible inclusion in 6.8 rc.