http: fix filter manager dropping a body frame on continue (#46842)

[jwendell]

Backport to release/v1.35. This is a cherry-pick of the release/v1.36
commit 0d9b3a8, which in turn
cherry-picked the main-branch commit 0871c75a6f329465c28cc6280cc904dc746d151b.

When an HTTP filter that is already iterating moves the current body
frame into the filter-manager buffer via
addDecodedData()/addEncodedData() and then returns Continue, the
buffered frame was silently dropped: the now-empty frame was forwarded
down the chain instead of the just-buffered bytes.

This corrupts streamed request/response bodies. It was observed by the
Kuadrant wasm-shim project, where a wasm filter using
allow_on_headers_stop_iteration stops on headers, resumes
asynchronously, and then buffers a body chunk before continuing; chained
ahead of an ext_proc filter in FULL_DUPLEX_STREAMED mode, one body
chunk was lost end-to-end. The defect is in core
commonHandleAfterDataCallback() and is not wasm- or ext_proc-specific.

The Continue path now forwards the filter-manager buffer instead of
the empty frame when the filter drained the frame while already
iterating. The behavior is guarded by the runtime feature

envoy.reloadable_features.filter_manager_forward_added_data_on_continue
(default-on) so it can be reverted if needed.

Adds a FilterManager unit test covering both guard states and an
ext_proc FULL_DUPLEX_STREAMED integration test (with a new
add-data-and-continue-filter test filter) asserting byte-exact body
delivery.

Backport notes (changes needed to resolve conflicts against 1.35):

• The source fix (filter_manager.cc/.h), the FilterManager unit test,
  the new add-data-and-continue-filter test filter and its BUILD
  wiring all applied cleanly.
• source/common/runtime/runtime_features.cc: only added the
  filter_manager_forward_added_data_on_continue guard; the unrelated
  generic_proxy_codec_buffer_limit and
  ext_proc_inject_data_with_state_update guards in the surrounding
  1.36 context do not exist on 1.35 and were dropped.
• 1.35 predates the 1.36 ext_proc test refactor, so it has no
  ext_proc_full_duplex_integration_test.cc. That file was dropped and
  its single new test AddDataAndContinueBeforeExtProcDuplexStreamed
  was ported into 1.35's monolithic ext_proc_integration_test.cc,
  adapting it to the duplex-streamed helper names/signatures present on
  1.35 (serverReceiveHeaderReq, serverSendHeaderResp, and the
  serverReceiveBodyDuplexStreamed/serverSendBodyRespDuplexStreamed
  helpers that take the processor stream as an argument).

Closes: #46841

[jwendell]

Depends on #618 to be merged first; Then I'll rebase and fix some conflicts/overlapping.

[dcillera]

This is a clean, faithful cherry-pick of an upstream-reviewed fix (envoy #46842/#46841) that addresses data loss in the HTTP filter manager. The core production change is small and sound:

• Both call sites of the changed commonHandleAfterDataCallback signature are correctly updated.
• The runtime guard (filter_manager_forward_added_data_on_continue) is properly registered and named.
• The ext_proc integration-test helper signatures match the 1.35 definitions.
• The changelog directory format is correct for this branch.

The related test:

//test/extensions/filters/http/ext_proc:ext_proc_integration_test'
//test/common/http:filter_manager_test

have been successfully executed locally.