Allow resize-merged-blocks with equal bundle sizes

[sduchesneau]

tools resize-merged-blocks now accepts equal --source-bundle-size and --target-bundle-size so merged-blocks files can be rewritten with different settings (ex: compression). It asks for confirmation; --force skips the prompt.

[dfuse-bot]

🔍 Vulnerabilities of ghcr.io/streamingfast/firehose-core:07dcdac-arm64

📦 Image Reference ghcr.io/streamingfast/firehose-core:07dcdac-arm64

digest	sha256:c432699c365503c8a5dc3f83e79f8455fbce44713a6378345b424ea3f5dff43e
vulnerabilities
platform	linux/arm64
size	155 MB
packages	507

📦 Base Image ubuntu:24.04

also known as	noble noble-20260917
digest	sha256:08571ca13e00ca07a2a84eab83a959b4242e22cceb16486a11bef1428c9e93a7
vulnerabilities

golang.org/x/net 0.59.0 (golang) pkg:golang/golang.org/x/net@0.59.0 Affected range <0.60.0 Fixed version 0.60.0 Description The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control. Affected range <0.60.0 Fixed version 0.60.0 Description A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values. Affected range <0.60.0 Fixed version 0.60.0 Description Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling. Affected range <0.60.0 Fixed version 0.60.0 Description When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.