Gzip encoding enforced for proxy

Nobody has claimed this yet.

I have OLS server serving static content and python server behind it for dynamic content:
httpd_config.conf:
```
extprocessor python-backend {
type proxy
address localhost:5000
maxConns 2000
initTimeout 10
retryTimeout 2
respBuffer 0
}
```
virtual_host.conf:
```
context /proxied {
type proxy
handler python-backend
addDefaultCharset off
}
```

when I am getting content without any headers there is no compression:
```shell
curl -iv https://server_host -o curl_out 2>&1 | grep -i encoding
```
it is OK, setting header -H "Accept-Encoding: br":
```shell
curl -iv https://server_host -o curl_out -H "Accept-Encoding: br" 2>&1 | grep encoding
> accept-encoding: br
< content-encoding: br
```
so brotli works....
And now for proxied without header also there is no content-encoding, but with header:
```shell
curl -iv https://server_host/proxied -o curl_out -H "Accept-Encoding: br" 2>&1 | grep encoding
> accept-encoding: br
< content-encoding: gzip
```
so there is "gzip" instead of "br"

Could you please check what is going on here?

Checked on OpenLiteSpeed 1.7.13 version.

Start by reproducing the curl requests against the httpd_config.conf and virtual_host.conf proxy setup on OpenLiteSpeed 1.7.13, comparing requests with and without Accept-Encoding: br. Trace the proxy response compression path to determine why it returns gzip for the proxied request; done means the behavior is explained and the expected encoding is covered by a regression check.

Written by the indexing model from the issue text.