RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration

## Summary A logic and resource exhaustion vulnerability exists in the AMQP client's Quality of Service (`Qos`) configuration method. The `Qos` function accepts signed integers (`int`) for the `prefetchCount` and `prefetchSize` parameters but casts them directly to unsigned integers (`uint16` and `uint32`, respectively) when formatting the wire-level frame. If a developer passes a negative integer (such as `-1`) to these parameters—frequently intended as a sentinel value meaning "no change" or "no limit"—the application performs an implicit signed-to-unsigned conversion. This wraps the values to their absolute maximum limit ($65535$ and $4294967295$). Consequently, a consumer expecting restricted message delivery rates is suddenly flooded with an unlimited volume of messages, potentially exhausting memory resources and crashing the application. --- ## Vulnerability Details ### Mechanism The bug manifests during the structural assignment inside the channel's `Qos` method: ```go // channel.go:795-796 PrefetchCount: uint16(prefetchCount), // -1 wraps to 65535 PrefetchSize: uint32(prefetchSize), // -1 wraps to 4294967295 ``` In Go, converting a negative signed integer to an unsigned integer shifts the value via two's complement arithmetic. Because no boundary validation or signedness check occurs prior to the cast: * Passing `-1` for `prefetchCount` yields a wire value of `65535`. * Passing `-1` for `prefetchSize` yields a wire value of `4294967295`. ### Impact The AMQP broker in