[Core] Avoid O(n^2) header dedup when cloning EF_UNIQ_HEADERS events

[celliso1]

Description

Problem

switch_event_dup() clones a source event by re-adding every header with
switch_event_add_header_string(). When the source has EF_UNIQ_HEADERS
set — which is the case for SWITCH_EVENT_CHANNEL_DATA,
SWITCH_EVENT_REQUEST_PARAMS and SWITCH_EVENT_MESSAGE, i.e. the events
used to hold a channel's variable list — the destination inherits the
flag, so switch_event_base_add_header() calls switch_event_del_header()
(a full linear scan of the list built so far) on every add to enforce
uniqueness. Duplicating an N-header event is therefore O(n²).

The scan is wasted work: the source list is already unique (uniqueness was
enforced when each header was first inserted), so copying it can never
create a duplicate, with or without the per-add scan.

Why it matters

switch_event_dup() backs switch_core_get_variables() and
switch_channel_get_variables(), which clone an EF_UNIQ_HEADERS
variable event. Any workload that duplicates large EF_UNIQ_HEADERS
events — channel-variable snapshots, or ESL consumers cloning big
events — pays this O(n²) on every dup.

On a production voicemail box carrying ~191 channel variables per call,
switch_event_del_header_val() (the per-add uniqueness scan) is 47–69%
of FS CPU in perf, and call-graph profiles show a substantial share
reached through execute_on -> *_get_variables -> switch_event_dup — the
path this patch fixes.

Scope: this patch fixes the dup path only. del_header_val is also
reached via switch_event_merge() (also in execute_on) and per-variable
switch_channel_set_variable(); those are separate O(n²) paths this
change does not address (future work: avoid the dup+merge in execute_on,
or hash-index event headers). The exact prod split between these callers
is not yet quantified.

Fix

Clear EF_UNIQ_HEADERS on the destination for the duration of the copy
loop in switch_event_dup(), then restore it. ~10 lines, no API change.

Microbench

tests/unit/switch_event.c (dup_uniq_bench), dup of an N-header
CHANNEL_DATA event, 4000 iterations, time per dup:

N	before	after	speedup
50	4.80 µs	3.19 µs	1.5×
100	11.34 µs	5.88 µs	1.9×
191	28.29 µs	10.99 µs	2.6×
400	107.05 µs	23.27 µs	4.6×

Real-call validation

Validated on production voicemail hosts under real deposit load — across
CPU, hypervisor, and FreeSWITCH version. Same-node, before vs after
swapping in the patched lib (40 s perf windows, self-time):

environment	del_header_val stock	patched	reduction
VMware / Intel / 1.10.12	56.7% of FS CPU	8.5%	−85%
VMware / AMD / 1.10.12	51.4%	7.9%	−85%
Proxmox / EPYC / 1.11.1	~47%	6.4%	−86%

A consistent ~85% reduction in the per-add uniqueness scan across all
three environments — the cache-bound Intel box (highest stock cost) drops
the most in absolute terms, −48 points of FS CPU. The call-graph
confirms the mechanism: with the patch the
switch_channel_execute_on → *_get_variables → switch_event_dup chains no
longer reach del_header_val; the ~6–8% residual is a separate path
(switch_event_merge, also reached from execute_on) that this change
deliberately does not touch.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Code cleanup / refactor

Testing

Profiled on production voicemail deposit service.

• Added/updated unit tests
• Tested manually
• Tested with live SignalWire credentials (if applicable)

Checklist

• I have read the CONTRIBUTING guidelines
• My code follows the project's style guidelines
• I have added tests for my changes (if applicable)
• I have updated documentation (if applicable)
• All existing tests pass

[celliso1]

@andywolk — would you have a moment to look at this? It's a self-contained ~10-line hot-path fix (O(n^2) -> O(n) in switch_event_dup() for EF_UNIQ_HEADERS events) with unit + regression tests.

Since opening it I validated the change on a production voicemail fleet — same-node before/after under real deposit load — and the win holds across CPU, hypervisor, and FreeSWITCH version:

environment	del_header_val stock	patched
VMware / Intel / 1.10.12	56.7%	8.5%
VMware / AMD / 1.10.12	51.4%	7.9%
Proxmox / EPYC / 1.11.1	~47%	6.4%

A consistent ~85% reduction in the per-add uniqueness scan (also summarized in the PR body). Happy to adjust anything — thanks!