When supporting streaming partial writes, the cache miss request may not
always find the corresponding body reader for the storage asset that its
upstream write is trying to fill.
This change adds a lookup_streaming_write storage API and allows the
miss handler to provide a streaming write tag for use with the API, so
that it may find the matching hit handler to serve downstream.
This changes the memory ordering for the lock status load to `SeqCst` from
`Relaxed` to eliminate a potential source of panics.
Panics had the frames:
```
pingora_proxy::proxy_cache::<T>::handle_lock_status (proxy_cache.rs:748)
pingora_proxy::proxy_cache::<T>::proxy_cache::{{closure}} (proxy_cache.rs:211)
pingora_proxy::HttpProxy<T>::process_request::{{closure}} (lib.rs:509)
pingora_proxy::HttpProxy<T>::process_new_http::{{closure}} (lib.rs:727)
```
which showed we were checking on the status of the lock, after waiting on it,
and still seeing its status as waiting. The status is returned by value, so this
is not a time-of-check to time-of-use problem, this is an inconsistency in how
the lock status is managed. The change in memory order is mostly for the sake of
this programmer's attempts to understand what is happening.
This also completes a couple of TODOs to limit the wait period as well as tag
the span with the lock status.
There could be a race condition where a Stale request waiting on cache
lock retries the cache lock and lookup, but enters cache_miss after
finding the asset is no longer present.
https://github.com/cloudflare/pingora/issues/181
Ran:
```
rg --pcre2 '(?<!(trace\!\()|(println\!\()|(warn\!\()|(info\!\()|(debug\!\()|(format\!\()|(error\!\()|(write\!\()|(panic\!\())\".*\{.+\"'
```
and audited the 200+ results by hand. Only messed up in a few places!
Hat-tip to Kevin for helping me understand the compile error messages I was
seeing trying to fix this naively.
And other things.
Co-authored-by: DimanNe <causal.consistency@proton.me>
Co-authored-by: Xiaobo Liu <cppcoffee@gmail.com>
Co-authored-by: houseme <housemecn@gmail.com>
Co-authored-by: lilo <luolee.me@gmail.com>
Co-authored-by: Yang He <abruzzi.hraig@gmail.com>
