write_to_port of a value the connected typed port cannot deserialize FW_ASSERT-aborts the FpySequencer

[zimri-leisher]

popSerializable_directiveHandler FW_ASSERTs on whatever status serialOut_out returns (FpySequencerDirectives.cpp:1796), but when serialOut[i] is connected to a typed input port — the normal flight wiring — the generated invokeSerial deserializes the port arguments and returns a failure status for a value that is too short, so a sequence can abort the sequencer with SIGABRT instead of failing the sequence. The compiler cannot prevent it, because write_to_port's value parameter is SIZED and port signatures are unknown to it (#179), and the WasmSequencer handles the same status gracefully with SerialPortSendFailed + hostResponseFailure (WasmSequencerInterpreter.cpp:492). The fix is for the directive to return a DirectiveErrorCode (there is no code for this case yet) rather than assert; note that a value that is too long is silently accepted with the extra bytes ignored.

Reproduced by wiring serial port 0 to the tester's typed Fw.Time input port (11 serialized bytes) in test/harness/FpySequencerTester.cpp:

seq.set_serialOut_OutputPort(0, this->get_timeGetIn_InputPort(0));

write_to_port(Svc.Fpy.SerialPortIndex.EXAMPLE_PORT_0, U8(1))

Assert: ".../Svc/FpySequencer/FpySequencerDirectives.cpp:1796" 5   # FW_DESERIALIZE_SIZE_MISMATCH
FpyHarness: .../Fw/Types/Assert.cpp:128: void Fw::defaultSwAssert(...): Assertion `false' failed.

Same class as #200 and #193 (sequence content reaching an FW_ASSERT in flight code).

[zimri-leisher]

Filed upstream as nasa/fprime#5859, since the fix is in Svc::FpySequencer's directive handler. To be clear about what that fixes: it stops the FSW aborting, but a sequence can still send a payload the port cannot use — catching that on the ground needs port signatures in the compiler (#179), and a payload longer than the port's arguments is silently accepted because invokeSerial ignores leftover bytes.