avoid undefined shift in hpack DecodeInteger on crafted integer

[ubeddulla]

What problem does this PR solve?

Issue Number:

Problem Summary:
DecodeInteger keeps consuming HPACK continuation octets while tmp < MAX_HPACK_INTEGER. A run of 0x80 octets carries a zero payload, so tmp never grows and that guard never trips, while the shift amount m keeps climbing; once m reaches 64 the << m on a uint64_t is undefined behavior. UBSan reports shift exponent 70 is too large for 64-bit type. It is reachable from any HTTP/2 or gRPC peer via a crafted HEADERS frame whose index is encoded as 0xFF followed by continuation octets.

What is changed and the side effects?

Changed:
Reject the over-long encoding once m reaches 32, before the shift can leave the type width. A valid integer below MAX_HPACK_INTEGER needs only a handful of continuation octets, so no well-formed input is turned away. A regression test in brpc_hpack_unittest.cpp decodes 0xFF plus a long run of 0x80 and checks it is rejected.

Side effects:

• Performance effects: one extra comparison per continuation octet, no measurable change.

• Breaking backward compatibility: none.

---

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.