Silence logic around error event broken on semaphore timeout

[skliper]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
If the semaphore times out there's no attempt to allocate a buffer. If a buffer isn't allocated and silent is false, an error event is sent claiming there was no buffer available.

CF/fsw/src/cf_cfdp_sbintf.c

Lines 91 to 116 in b0269ef

	if (OS_ObjectIdDefined(c->sem_id))
	{
	os_status = OS_CountSemTimedWait(c->sem_id, 0);
	}
	else
	{
	os_status = OS_SUCCESS;
	}
	/* Allocate message buffer on success */
	if (os_status == OS_SUCCESS)
	{
	CF_AppData.engine.out.msg = CFE_SB_AllocateMessageBuffer(offsetof(CF_PduTlmMsg_t, ph) + CF_MAX_PDU_SIZE +
	CF_PDU_ENCAPSULATION_EXTRA_TRAILING_BYTES);
	}
	if (!CF_AppData.engine.out.msg)
	{
	c->cur = t; /* remember where we were for next time */
	if (!silent)
	{
	CFE_EVS_SendEvent(CF_EID_ERR_CFDP_NO_MSG, CFE_EVS_EventType_ERROR,
	"CF: no output message buffer available");
	}
	success = false;
	}

This silent logic doesn't make any sense to me, since it's passed in as 0 from all the non-file data PDUs but 1 for data. If it was intended for the allocate buffer why only non-data PDUs? I doubt it was ever intended for the semaphore timeout.

To Reproduce
I saw it when waiting for the semaphore to send an Eof PDU. Could probably see it on the metadata send, but I initialize w/ a nonzero sem count.

Expected behavior
No event on semaphore timeout, this is nominal behavior for flow control. TBH I'm not a huge fan of a possible flooding event on the failure to get a buffer. I'd rather see a combined approach of a counter and probably a single event sent at the maximum rate of each HK cycle only when the counter increments.

Code snips
See above.

System observed on:
Ubuntu 20.04

Additional context
None

Reporter Info
Jacob Hageman - NASA/GSFC