Fixed data loss bug in the core

[haberman]

When there are exactly 32 hasbits, we were allocating only 4 bytes for hasbits, leading to an overlap in the message layout. Hasbits were being allocated to the same offset as a regular data member. This caused data corruption.

upb's hasbits are identified by a zero-based index, so the hasbit can be calculated with 1 << index. However we do not use hasbit index 0, as 0 indicates "no presence" (either a proto3 singular field, or a repeated/map field). Therefore 32 hasbits will be assigned to the indexes 1-32. The value 1 << 32 exceeds four bytes, and therefore requires that we allocate at least five bytes to hasbits. But our math had an off-by-one error:

  hasbit_bytes_ = DivRoundUp(hasbit_count_, 8);

This expression evaluated to four when hasbit_count_ is 32. The fix is to add one, so that when we are using hasbit index 32, we allocate five bytes instead of four.

Fixes: protocolbuffers/protobuf#9440 (this will require an explicit sync to Ruby & PHP).