Reset write lock state to init after closing write

[JosiahWI]

This commit mitigates the crash reported in #11700. That crash happens when a redirect is issued on a state machine that has already cached a response and closed the cache write VC.

After this patch, the state machine will likely open a new cache VC to cache the response from the origin it was redirected to. We will refer to the original origin as A, and the origin the state machine was redirected to after the response from A as B.

We have not yet reproduced this locally - the exact sequence of events that gets the state machine into this state are still unknown.

Some things to pay attention to for review:

• Normal behavior is to cache B's response under A's URI. In the edge case this patch mitigates, A and B's responses will both be cached, possibly with B's response overwriting A's, or maybe not... this is still untested.
• This does a second cache write when normally only one cache write occurs during a state machine's lifetime. Are both writes independent from each other's state, and properly cleaned up to prevent memory leaks?
• Are there other places where the write lock should also be reset?
• Can the escalate plugin force a redirect to happen after kill_this() has been called (we tried to detect this with a release assert, and did not).

Resolves #11700.

[Copilot]

Pull Request Overview

This PR addresses a crash related to cache write closures by ensuring that the write lock state is reset to its initial value (CACHE_WL_INIT) after closing the cache write path.

• Reset the write lock state after closing cache writes in two different functions.
• Aims to mitigate crashes when a state machine reopens a cache VC after a redirect.

Comments suppressed due to low confidence (2)

src/proxy/http/HttpSM.cc:6463

• Adding the write lock state reset immediately after closing the cache write appears correct, but please ensure that all code paths that perform a cache write closure are updated similarly to avoid any inconsistent state issues.

t_state.cache_info.write_lock_state = HttpTransact::CACHE_WL_INIT;

src/proxy/http/HttpSM.cc:6522

• The write lock state reset here should be verified against all related code paths. Consider consolidating the write lock reset logic into a shared helper if it is repeated elsewhere to improve maintainability.

t_state.cache_info.write_lock_state = HttpTransact::CACHE_WL_INIT;

[masaori335]

The root cause of the crash is a bit unclear, but reseting the write_lock_state after HttpCacheSM::close_write() seems reasonable.

[masaori335]

I'd point out one thing, if this only happens on following redirect, resetting the write_lock_state in HttpSM::redirect_request like object_read is another idea. However, it might have other side effects. Obviously, following redirect needs refactoring.

https://github.com/apache/trafficserver/blob/master/src/proxy/http/HttpSM.cc#L8437-L8439

[cmcfarlen]

Cherry-picked to 10.1.x branch