Fix #1157, increment sequence if indicated

[jphickey]

Describe the contribution
Do not restrict sequence increment to TLM only, since CMD packets can be locally generated too (e.g. SCH, TIME).

Fixes #1157

Testing performed
Build and sanity check CFE, run all unit tests.

Expected behavior changes
All transmitted messages will get their sequence count incremented if transmitted with parameter IncrementSequenceCount set to true. Previously, for some reason, this flag was only honored on TLM packets.

System(s) tested on
Ubuntu 20.04

Additional context
Thus far I've not found a real reason/explanation as to why this flag would be ignored for CMD packets. If there is a good reason, it should be documented. Otherwise for the sake of consistency it should be done for all messages.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Tagging @acudmore and @jwilmot in case they can offer some history on this subject.

As it stands we handle CMD vs. TLM packets inconsistently - basically we ignore the "IncrementSequenceCount" flag if it is a command - without really any explanation/justification as to why we would ignore it. I'm suggesting removing this to make it consistent, but there may be some history I'm not aware of.

My recommendation would be - if there is a use case where the counter shouldn't be incremented, why can't the caller just set this parameter false ...?

[astrogeco]

CCB:2021-04-07

• This has a history and we need to be careful changing this
• In the previous builds there was no option to increment the sequence count so the behavior was implicit
• Could be related to command authentication
• Needs a splinter
• Document the "unexpected" behavior so it is obvious