Add helper to set protocol fees by factory

[EndymionJkb]

Description

This adds a ProtocolFeePercentagesProvider helper contract that allows governance to set protocol fee percentages at the factory level, and then a permissionless function to propagate these fee percentages to individual pools. (Well, permissionless after governance grants the provider contract permission to set pool fees.)

An important design constraint was building this on top of the existing infrastructure, with no new dependencies (e.g., not changing existing factories, or adding new requirements for factories, such as keeping an enumerable set of pools, or calling back into anything to register new pools, etc.)

There are no changes to existing contracts: except adding a getter for the maximum swap/yield fee constants to the ProtocolFeeController, which it arguably should have anyway. This avoids duplicating constants, and divergence from the current ProtocolFeeController.

It has two important functions:

setFactorySpecificProtocolFeePercentages: a permissioned call to set fee percentages by factory. It does some validation that isn't strictly necessary: ensuring that the fees being set are <= max allowed values, and a "best effort" check that the factory is a real factory (i.e., that responds correctly to isPoolFromFactory calls). Otherwise, you could set values that would fail when you tried to apply them.

setProtocolFeePercentagesForPools: a permissionless call to apply the fee percentages to a set of pools from a given factory. This was over-engineered at first (as I tend to do), taking just a set of pools, and having the contract figure out which factories they belonged to and fetch the corresponding fee percentages. But that required an enumerable set of factories, a "find" function, etc. Probably people are going to set the fees for one factory at a time, using the subgraph, so I think making it completely generic is overkill.

It should cut down on governance calls, since they need only approve the factory-wide defaults, not the list of individual pools. No further governance action would be needed for new pools from that factory, as the "propagation" call is permissionless.

Type of change

• Bug fix
• New feature
• Breaking change
• Dependency changes
• Code refactor / cleanup
• Optimization: [ ] gas / [ ] bytecode
• Documentation or wording changes
• Other

Checklist:

• The diff is legible and has no extraneous changes
• Complex code has been commented, including external interfaces
• Tests have 100% code coverage
• The base branch is either main, or there's a description of how to merge

Issue Resolution

Resolves #888

[elshan-eth]

LGTM!