Extend ~TypeInfo scribble to cover ClassData function pointers

[jortles]

Summary

The existing scribble in ~TypeInfo (dynamic_message.cc:467-477) covers offsets[] and has_bits_indices[] to catch use-after-free bugs where the factory is destroyed but DynamicMessage instances are still used. The comment on line 470 notes this is "a common bug with DynamicMessageFactory." However, the ClassData function pointers are not scribbled:

// dynamic_message.cc:857
const internal::ClassData* DynamicMessage::GetClassData() const {
    return type_info_->GetClassDataFull().base();  // dereferences raw type_info_
}

After factory destruction, type_info_ points to freed memory. GetClassData() returns a pointer into the freed TypeInfo's ClassData, and downstream operations call through its function pointers:

• IsInitialized() / SerializeToString() → data->is_initialized(*this) (message_lite.cc:101)
• MergeFrom() → data->merge_to_from(to, from) (message_lite.cc:119)
• New() → data->message_creator.PlacementNew(...) (message_lite.h:444)
• _InternalParse() → TcParser::ParseLoop(this, ..., GetTcParseTable()) (message_lite.cc:106)

Root cause

The scribble mitigation in ~TypeInfo was added to detect the factory-outlives-messages bug pattern, but only covers the offsets[] and has_bits_indices[] arrays. The ClassData function pointers (is_initialized, merge_to_from, message_creator, tc_table) embedded in TypeInfo (or in globals in PROTOBUF_MESSAGE_GLOBALS builds) are left intact in freed memory.

Downstream impact

• IsInitialized() (message_lite.cc:101): Calls data->is_initialized(*this) — indirect call through freed pointer.
• MergeFrom() (message.cc:176): Calls data->merge_to_from — indirect call through freed pointer.
• New() (message_lite.h:439-445): Calls data->message_creator.AllocateMessage() and PlacementNew() — indirect calls through freed pointer.
• _InternalParse() (message_lite.cc:106): Reads tc_table from freed memory, passes to TcParser::ParseLoop.
• ~DynamicMessage(): Reads type_info_->GetClassDataFull() during destruction — reads freed memory.

With the existing scribble, only GetInt32/GetString etc. via offsets[] are caught (they read the scribbled 0xCDCDCDCD sentinel). The function pointer paths silently use stale freed data.

Fix

Null out the ClassData function pointers (tc_table, is_initialized, merge_to_from) and default-initialize message_creator before calling SizedDelete. In PROTOBUF_CUSTOM_VTABLE builds, also null destroy_message, clear, byte_size_long, and serialize. Cache allocation_size() before scribbling message_creator, since the SizedDelete call needs it.

This must happen before SizedDelete because in PROTOBUF_MESSAGE_GLOBALS builds, SizedDelete frees the globals allocation which contains ClassData.

After this change, any accidental use of a DynamicMessage whose factory has been destroyed will hit a null function pointer (immediate crash with a clear signal) instead of calling through stale freed memory.

Test plan

• All existing DynamicMessage* tests pass — no regression.
• The scribble is a mitigation, not a behavioral change. It converts stale-pointer calls into null dereferences for the factory-outlives-messages bug pattern that the existing scribble already targets.