Clarify CFE_TBL_NotifyByMessage should not use ground command MID

[skliper]

Is your feature request related to a problem? Please describe.
CFE_TBL_NotifyByMessage should use a separate MID from ground commands to avoid command counter increments (and any other ground specific processing).

Describe the solution you'd like
Update documentation to explicitly recommend NOT using ground command MID.

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

EDIT - changed per comments below from a command code issue

[jphickey]

It actually is sending a command though. This function itself isn't a command, but it it instructs tbl services to send a command whenever the table gets updated.

I'm not seeing the issue here....

Note that even "HK" type messages actually do have a command header anyway. CCSDS doesn't support "bare" packets with no content, we must include the command header, so it must be filled with something.

[skliper]

This message should not increment the command counter (or invalid if there's a processing issue), and like HK would be better to not use the typical ground command MID. That's the real restriction. Probably just a documentation thing.

My concern is probably an artifact of insufficiently defined requirements, where "command" has specific associated requirements when really we need to somehow differentiate between messages that should and shouldn't increment the command counter. Agreed it still needs to be a "command" type CCSDS message (since TLM definitely doesn't make sense and we only get two choices), but it shouldn't be treated like a ground command.

[jphickey]

Yes, that's fine but it strikes me more as a system engineering issue not an API issue. While it's true this notification could send a fully-fledged "command' that increments a command code, that doesn't mean it must do this.

If it really is a concern, just document that the message sent should not be one that increments the command count at the receiver. But I don't see any reason to change the API.

[skliper]

Agreed, as I said...

Probably just a documentation thing.