Potential gas optimization in the Broker struct

[PaulRBerg]

We might be able to save some gas in the Broker struct by tightly packing the addr and the fee fields.

We would pack them by using the UD2x18 type instead of UD60x18. address has 160 bits and UD2x18 64 bits, so in total 224 bits, which is less than 256.

There are two downsides, though:

1. We would have to also refactor the protocolFee to be an UD2x18.
2. The UD2x18 type is a bit counter-intuitive - the maximum value is ~18.44, which is not what you expect from a type that purportedly "can have up to 2 digits" in the whole part.

Howeveeere, the second downside is a weak contention, because we are already using the UD2x18 type in the segment exponent, and so we would have to document and explain its internal logic anyway. In fact, it might be a good thing to stick with using a single PRBMath value type in the public smart contract API.

[andreivladbrg]

We might be able to save some gas in the Broker struct by tightly packing the addr and the fee fields.

That's a struct for memory purpose, tightly packing is much more relevant on storage actions. If we won't change the protocolFee it wouldn't be worth it due type conversions.

[PaulRBerg]

Shoot, you're right!

Then the question really is - does it make sense to change protocolFee to UD60x18?

I don't think it does, because it's stored directly as a value in a mapping (instead of as a field in a struct):

https://github.com/sablierhq/v2-core/blob/873d4f67a7d85351fcf0ada2acf2057bb130f7d8/src/SablierV2Comptroller.sol#L32

[PaulRBerg]

Locking based on @andreivladbrg's observation that the Broker struct is only used in memory.