Fix cFS DoS via Unvalidated AppEntryPoint

[aw0lid]

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov.

Description

This Pull Request addresses the Denial of Service (DoS) vulnerability reported in #2684. It adds a validation layer within CFE_ES_AppCreate to ensure that the requested AppEntryPoint (symbol name) is not already in use by any active application or core service.

Fix Logic

The fix implements a two-tier validation strategy for the AppEntryPoint:

1. Namespace Protection: Pre-emptively rejects entry points starting with reserved prefixes (CFE_ or OS_). This prevents external apps from attempting to reuse core system symbols.
2. Redundancy Check: Iterates through the AppTable while holding the SharedData lock to verify if the provided InitSymbolName is already in use by another running application.

This ensures the system rejects unauthorized or conflicting entry points before resource allocation, preventing OSAL mutex name collisions and fatal system aborts (SIGABRT).

Testing Performed

Verified on cFS Draco (v7.0.0).

• Test Method: Used a custom Python script to inject raw UDP CFE_ES_START_APP_CC packets.
• Scenario 1 (Core Symbol): Attempted to start an app with AppEntryPoint set to CFE_ES_Main.
• Scenario 2 (Duplicate App): Attempted to start an app with AppEntryPoint set to SCH_LAB_AppMain (already running).
• Observed Result: In both cases, the system correctly caught the conflict, logged the specific rejection reason to SysLog, and returned CFE_ES_ERR_DUPLICATE_NAME.
• System Stability: The core remained operational; no SIGABRT or IOT instruction crashes occurred.

Impact

• Increases system robustness against unvalidated ground command parameters.
• Prevents accidental or malicious system-wide crashes due to symbol reuse.

Closes #2684

[sylvesterkaczmarek]

The prefix filter looks narrower than the underlying failure mode. On POSIX, module-scoped dlsym(handle, name) can resolve symbols from the module dependency closure, so a ground command could still select a non-CFE_/OS_ exported dependency symbol that was never intended as an app entry point. Could the validation verify that the resolved address belongs to the module being loaded rather than authorizing by symbol-name prefix?