Enforce worker limits in Compression Streams API

[fhanau]

No description provided.

[fhanau]

This is modeled after the limiting approach recently added in dh.c++ and should avoid CPU utilization issues when compressing a large amount of data at once.
Some things I'm not sure about:

1. This assumes that querying the limiter is somewhat expensive. Hence, we try to avoid it if the output data fits into the output buffer, so that we don't need to query this every time when compressing small amounts of data/compressing data in small chunks which should already get limited properly. Is there actually such overhead, for example from having to acquire locks?
2. Is this the right spot for this to apply exception handling correctly?

[anonrig]

Is this easily testable? I feel such that should have a test that validates the behavior.

[jasnell]

Testing this in workerd is likely difficult since we do not actually implement the cpu limiting functionality (it's all a non-op in workerd). We'll likely need to add a test to the internal repo separately.

[jasnell]

Labeling as "needs-internal-pr" so that we can get a test added internally to verify this

[jasnell]

So one key bit here is that I don't believe we are yet reporting the size of the buffer here to v8, so v8 itself won't really have any insight into the memory consumed by the decompression itself -- that is, unless these chunks are immediately being moved into a v8::ArrayBuffer. So I'm not sure if the memory check here will be effective? Have you been able to verify this appropriately accounts for the memory used during decompression?

[fhanau]

This change was designed with CPU time limiting in mind; it does not take any additional steps to accurately measure memory consumption, but once that is implemented properly it should be able to limit that too. I can add a comment indicating this.

[fhanau]

Downstream PR and test have been added.