Fix set-body at remap and escalate plugin interaction with internal_msg_buffer

In EndRemapRequest, the previous fix unconditionally cleared
internal_msg_buffer in the else branch (remap success path).
This destroyed the body set by set-body at remap hooks when no
set-status was used, causing ATS to contact the origin instead
of serving the synthetic response.

Fix: Only clear internal_msg_buffer when a plugin tunnel is
active (the original intent - clearing stale error bodies from
build_error_response during remap failures for plugin tunnels).

Also clear internal_msg_buffer in redirect_request() to prevent
stale error bodies from build_error_response (e.g., connection
failures) from being mistaken for plugin-set synthetic bodies
by how_to_open_connection() during redirect/retry flows like
the escalate plugin.

Author: bryancall

src/proxy/http/HttpSM.cc

@@ -8558,6 +8558,10 @@ HttpSM::redirect_request(const char *arg_redirect_url, const int arg_redirect_le
     // XXX - doing a destroy() for now, we can do a fileds_clear() if we have performance issue
     t_state.hdr_info.client_response.destroy();
   }
+  // Clear any error body from a previous failed connection attempt (e.g., from
+  // build_error_response) so that how_to_open_connection() does not mistake it
+  // for a plugin-set synthetic body and short-circuit the retry.
+  t_state.free_internal_msg_buffer();
 
   int         scheme          = t_state.next_hop_scheme;
   int         scheme_len      = hdrtoken_index_to_length(scheme);

src/proxy/http/HttpTransact.cc

@@ -1233,9 +1233,19 @@ HttpTransact::EndRemapRequest(State *s)
     Metrics::Counter::increment(http_rsb.invalid_client_requests);
     TRANSACT_RETURN(StateMachineAction_t::SEND_ERROR_CACHE_NOOP, nullptr);
   } else {
-    s->hdr_info.client_response.destroy(); // release the underlying memory.
-    s->hdr_info.client_response.clear();   // clear the pointers.
-    s->free_internal_msg_buffer();         // clear error body so plugin tunnel is not bypassed.
+    // This else branch handles two cases:
+    // 1. Remap succeeded (reverse_proxy == true) - normal request processing
+    // 2. Remap failed but plugin tunnel exists - plugin overrides error
+    //
+    // For case 2, clear the stale error response that build_error_response()
+    // created during remap failure, because the plugin tunnel will provide
+    // its own response. For case 1, preserve any plugin-set internal_msg_buffer
+    // (e.g., from set-body at remap) so how_to_open_connection() can short-circuit.
+    if (s->state_machine->plugin_tunnel_type != HttpPluginTunnel_t::NONE) {
+      s->hdr_info.client_response.destroy(); // release the underlying memory.
+      s->hdr_info.client_response.clear();   // clear the pointers.
+      s->free_internal_msg_buffer();         // clear error body so plugin tunnel is not bypassed.
+    }
     TxnDbg(dbg_ctl_http_trans, "END HttpTransact::EndRemapRequest");
 
     if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {