TCP traffic tapping with streaming uses max_buffered_rx_byte and max_buffered_tx_bytes

I've configured an upstream cluster to enable TCP traffic tapping, using the [admin-style](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/tap_filter#admin-handler) configuration that streams the data to the [/tap](https://www.envoyproxy.io/docs/envoy/latest/operations/admin#post--tap) admin endpoint. My upstream cluster configuration includes:

```yaml
"per_connection_buffer_limit_bytes": 131072,
"transport_socket": {
"name": "envoy.transport_sockets.tap",
"typed_config": {
"@type": "type.googleapis.com/envoy.extensions.transport_sockets.tap.v3.Tap",
"common_config": {
"admin_config": {
"config_id": "mtu.hserver-multi-tenant-upstream.cerberus"
}
},
"transport_socket": {
"name": "envoy.transport_sockets.tls"
}
}
},
```

Then I post this document to Envoy's `/tap` endpoint:

```yaml
config_id: mtu.hserver-multi-tenant-upstream.cerberus
tap_config:
match:
any_match: true
output_config:
streaming: true
sinks:
- streaming_admin: {}
```

This works except that when I drive an HTTP request with a large request or response body, the body data in each event document is always truncated at 1024 bytes, discarding anywhere between 32K to 80K bytes for each event. In order to prevent the truncation, I found I had to add:
```yaml
max_buffered_rx_bytes: 204800
max_buffered_tx_bytes: 204800
```
The [documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/tap/v3/common.proto#config-tap-v3-outputconfig) seems to indicate that these settings are only used for non-streaming captures, however. Is this a bug or intended? If it's intended, what value can I specify that would guarantee no truncation? I've noticed that it doesn't seem to be related to my `per_connection_buffer_limit_bytes`, at least not in an obvious way.

Oh, I should mention that due to recent tapping fixes, I tested this using the `envoy-dev` Docker image, specifically this version:

40de14954b29b4c1c87793482b90b27da3370f0f/1.17.0-dev/Clean/RELEASE/BoringSSL