CID 1489776: Questionable sign extension in congestion control logic

Looks like we're missing signed and unsigned here unintentionally. Let's resolve this by adding explicit casts as necessary so that we don't have to reason too hard about C's cursed integer promotion logic.

 /src/core/or/congestion_control_common.c: 789 in congestion_control_update_circuit_bdp()
783           uint64_t delta = now_usec - timestamp_usec;
784     
785           /* The acked data is in sendme_cnt-1 chunks, because we are counting the
786            * data that is processed by the other endpoint *between* all of these
787            * sendmes. There's one less gap between the sendmes than the number
788            * of sendmes. */
>>>     CID 1489776:  Integer handling issues  (SIGN_EXTENSION)
>>>     Suspicious implicit sign extension: "cc->sendme_inc" with type "uint8_t" (8 bits, unsigned) is promoted in "(sendme_cnt - 1) * cc->sendme_inc" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned).  If "(sendme_cnt - 1) * cc->sendme_inc" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
789           uint64_t cells = (sendme_cnt-1)*cc->sendme_inc;
790     
791           /* The bandwidth estimate is cells/delta, which when multiplied
792            * by min RTT obtains the BDP. However, we multiply first to
793            * avoid precision issues with the RTT being close to delta in size. */
794           sendme_rate_bdp = cells*cc->min_rtt_usec/delta;

cc: @mikeperry @dgoulet