CFE_SB_ReceiveBuffer does not return when the provided pipe is destroyed

[jbohren-hbr]

Describe the bug
If a pipe is destroyed while CFE_SB_ReceiveBuffer() is waiting with CFE_SB_PEND_FOREVER, CFE_SB_ReceiveBuffer() either blocks indefinitely or returns CFE_SUCCESS (non-deterministically). This behavior is demonstrated in the proposed test case in PR #1777.

This is situation is only realizable in a multi-task context. The functional tests included in #1651 / #1657 do not test this behavior because they do not create multiple tasks in which one task is waiting on a blocking call to CFE_SB_ReceiveBuffer() while the pipe provided to it is deleted.

To Reproduce
See test case in PR #1777

Expected behavior
The expectation (albeit not documented) is that if a pipe is deleted while waiting on CFE_SB_ReceiveBuffer(), that CFE_SB_ReceiveBuffer() would return immediately with an error code.

Code snips
See PR #1777

System observed on:
See PR #1777

Additional context
See PR #1777

Reporter Info
Jonathan Bohren, Honeybee Robotics

[skliper]

Worth noting I did just rediscover this caution about pipes not being inherently/originally designed as multi-thread safe:

cFE/docs/cFE Application Developers Guide.md

Lines 1536 to 1541 in e5d4ed9

	The first parameter returns the Pipe Identifier. This identifier is
	important when using other SB API functions. It is important to realize
	that the Pipe is not multi-thread safe. Therefore, it is illegal for
	another thread, even one from the same Application, to attempt to
	receive data from the created pipe. If multiple threads require access
	to messages, each thread needs to create their own pipe and make their own message subscriptions.

[jbohren-hbr]

Worth noting I did just rediscover this caution about pipes not being inherently/originally designed as multi-thread safe:

Understood. Note that in this use case (implemented in SBN), only one thread is reading the pipe. However, a second thread is responsible for creating and destroying the pipe dynamically at runtime.