Use `UDS_NRC_GeneralReject` for server app programming errors

[driftregion]

Just a heads up for your review:

In my code I opted to do a length check for the responses from the event callback to ensure compliance with the standard. But I am unsure on how to correctly propagate a length error to the client since no valid NRC's seem to fit this usecase.

Currently I respond wit the raw data from the callback (even if it is the wrong size), as it is also done in this way in the Handle_0x23_ReadMemoryByAddress function.

I see. This needs updating. My intent here is return NegativeResponse(r, ...) -- not returning the raw data. A length mismatch indicates server programmer error, in which case it makes the most sense to return no data other than the NRC.

iso14229/src/server.c

Line 292 in 4b4100b

return UDS_NRC_GeneralProgrammingFailure;

Other solutions I came up with are not responding at all and let the client run into a timeout or responding with NRC 0x10 (General Reject).

If you have a suggestion or an opinion on what would be the correct way to handle this, I'll update the code accordingly.

I think sending a UDS_NRC_GeneralReject is a good approach for server user implementation issues. Some history: I misinterpreted the meaning of UDS_NRC_GeneralProgrammingFailure. Its use in the other services is definitely inconsistent with the standard and needs updating to UDS_NRC_GeneralReject.

In summary, for all server user implementation issues, my preferred approach is:

1. Complain loudly with UDS_LOGE -- this allows the programmer to detect issues during bringup.
2. Return UDS_NRC_GeneralReject -- this correctly reflects that there was a server error.

Originally posted by @driftregion in #86 (comment)