Reuse deleted MIME field slots

[bneradt]

Long-lived MIME headers allocate field blocks as fields are added and
removed. HPACK exercises this path heavily, while the current attempt to
bound the block chain scans and destroys empty blocks during deletion.

This maintains a deleted-slot free list through m_next_dup and consumes
it before allocating another field block. Appending within a partially
filled tail preserves established field order. The free list is rebuilt
for copied or unmarshaled headers, and same-name duplicate order is
preserved.

This adds high-water churn, insertion-order, duplicate, copy, and
marshal coverage.

Fixes: #8466

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/proxy/hdrs/MIME.cc:1712

• Pushing a deleted slot onto the free list updates m_free_slot via mime_hdr_field_slotnum(), which linearly scans all field blocks to compute a slot number. Because this executes on every field delete, it may become a hot cost in the HPACK churn scenario this PR is targeting.

If possible, avoid computing slot numbers via mime_hdr_field_slotnum() in this fast path (e.g., encode the free list in a way that retains the next slot number directly).

    mh->m_free_slot   = mime_hdr_field_slotnum(mh, field);
    ink_release_assert(mh->m_free_slot >= 0);

src/proxy/hdrs/MIME.cc:1408

• This new free-list pop path computes the next head by calling mime_hdr_field_slotnum(), which does a linear scan over the field-block chain (see the note above that the function “needs to be removed” because it’s poorly performant). Since this runs on every allocation from the deleted-slot free list, it may offset some of the intended performance gain under HPACK churn.

Consider tracking the next free slot number without needing a block-chain scan (e.g., store the next-slot number alongside the free-list linkage, or otherwise avoid slotnum->pointer->slotnum round trips).

This issue also appears on line 1711 of the same file.

    mh->m_free_slot = field->m_next_dup ? mime_hdr_field_slotnum(mh, field->m_next_dup) : MIME_FIELD_FREE_SLOT_NONE;