Fix MQTT MISRA violations

[muneebahmed10]

Description of changes:
Fixes most MISRA violations in MQTT. The remaining violations with our current configuration are all 8.7 (External linkage for functions used in one translation unit), which is required for API functions. Note that the changes in commit "Remove useless const" aren't due to MISRA violations, we had just been adding const because we had them in v4_beta (due to other MISRA violations relating to function pointers). However, since C is pass by value I didn't find value in keeping them.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[muneebahmed10]

I think some wanted to get rid of our #define of bool, and others wanted to keep it. I don't believe there was a clear decision on that matter, and I don't think removing it is in scope for this PR. Note that due to the changes in this PR, removal (if desired) should be straightforward, just a search and replace of bool with the desired type, false with 0, and true with 1

[abhidixi11]

We must avoid annotation, for the new library.

1. Are we running Coverity in C99 mode ? because boolean expressions should evaluate to an integral value.
2. What happens if bool is defined as int32_t ? Usually type of boolean expression is int ( which should be either int32_t )
3. Other option is to change code as follows:
   if( newState == MQTTPubAckPending )
   {
   isValid = true;
   }

If there is no other way, then we should remove bool. Instead use BOOL / Bool something other than c99 bool.

[muneebahmed10]

1. I'm unsure what you mean by "C99 mode" but according to our cmake, we compile with std=c89. If we compile with C99 instead, then this isn't a violation, since the types of these values are actually booleans and not whatever we define them as for C89. This is only a violation when using C89.
2. The same violation occurs whether we define bool as int32_t, uint32_t, uint8_t, etc. The issue is that MISRA considers the outputs of relational operators as "essentially boolean types", which is different from "essentially signed" or "essentially unsigned", and won't allow even explicit casts between them. Since there's no data type in C89 that's "essentially boolean", MISRA will complain if we store these values to a variable. So removing bool and replacing it with anything else will not help either.
3. Yes, that is an option, however I was reluctant to do that earlier since it would greatly increase complexity of our functions due to increased nesting and lines of code, and they would have had to be split up in ways that didn't seem the most logical. However, I realized that instead of ifs, we can just use ? : instead, as that both solved the 10.5 issue and did not noticeably increase the complexity.

I reverted the annotation change and used the ternary operator instead

[abhidixi11]

Regarding #1 and #2 I thought in C89 / ANSI mode value of boolean should be int or "essentially signed". That's why I asked if Coverity is throwing that error because it sees bool which is c99 and considers it a data type. #3 was basically the same as you change, which avoid any casts. Your change looks good, approved. ( Just make sure ternary operator is not a problem MISRA )

[abhidixi11]

See my comment about annotations.

[gkwicker]

See comments