Refactor ingest to utilize zero copy (can reduce two copy to one)

[skliper]

Is your feature request related to a problem? Please describe.
CI copies the data into a local buffer and then uses CFE_SB_TransmitMsg (which does a second copy into the SB buffer):

ci_lab/fsw/src/ci_lab_app.c

Lines 359 to 374 in 296d12c

	void CI_LAB_ReadUpLink(void)
	{
	int i;
	int32 status;
	for (i = 0; i <= 10; i++)
	{
	status = OS_SocketRecvFrom(CI_LAB_Global.SocketID, CI_LAB_Global.IngestBuffer.bytes,
	sizeof(CI_LAB_Global.IngestBuffer), &CI_LAB_Global.SocketAddress, OS_CHECK);
	if (status >= (int32)sizeof(CFE_MSG_CommandHeader_t) && status <= ((int32)CI_LAB_MAX_INGEST))
	{
	CFE_ES_PerfLogEntry(CI_LAB_SOCKET_RCV_PERF_ID);
	CI_LAB_Global.HkTlm.Payload.IngestPackets++;
	status = CFE_SB_TransmitMsg(&CI_LAB_Global.IngestBuffer.Msg, false);
	CFE_ES_PerfLogExit(CI_LAB_SOCKET_RCV_PERF_ID);
	}

Describe the solution you'd like
Could use zero copy to get a buffer, write directly to the buffer and CFE_SB_TransmitBuffer (single copy)

Describe alternatives you've considered
None

Additional context
We don't have a functional example of zero copy, just documentation. This would support user request for a working example as well as improve performance.

Requester Info
Jacob Hageman - NASA/GSFC (from stakeholder request)

[jphickey]

I actually like the fact that this copies the packet, because CI/TO should someday take on the role of dealing with the differences between network encoding/padding and native encoding/padding.

That is, the "dumb" memcpy that is done now can be replaced with a "smart" endian- and padding- aware copy. It is the ideal place to do this because its transparent to all apps.

I don't want to re-open culture wars on the subject - even if some users don't want to do it this way for some reason - I'm just saying its a valid and useful option to have, and it works well (speaking from experience).

[jphickey]

After thinking about this for another minute - it's probably fine either way because even in the "smart" CI/TO copy case it can still use the zero copy method to send the message on once its been fixed up.

However - we do need to coordinate this with nasa/cFE#1155. That one is waiting right behind the reorganization stuff in nasa/cFE#1203.