Add LBPool

[gerrrg]

Description

tl;dr: Create a weight shifting LBPool for V3.

Note

This PR replaces and obsoletes #971 by turning it into a PR from the add-lbpool branch from w/in this repo rather than my fork.

What

• Port over the main functionality of LBPool from V2 to V3
• Port over the gradual value change library
• Create a WeightValidation library for improved portability (could use this in standard WP if desired)
• Adhere to events for V2 LBP to improve the ease of integration/compatibility
• Make the pool contract its own hook contract and do beforeJoin hook for onlyOwner LP
• Store info for only a single weight for higher precision/lower gas since weights must sum to FP.ONE
• Add relevant tests
• Modify some inherited tests (BasePoolTest.sol) to be more generalizable/override-able

Why

Modernize a highly popular feature from v2

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
• [tbd] Tests have 100% code coverage
• The base branch is either main, or there's a description of how to merge

Issue Resolution

n/a

[elshan-eth]

Looks good! I have a couple of minor comments

[jubeira]

Just a few minor comments, but otherwise looks great and makes a lot of sense.

Thanks @gerrrg ! And happy holidays btw :)
I'll take it from here.

[jubeira]

I see no reason in principle for this to change, but it does pose a maintainability question in case we ever migrate routers and the SDK / frontend need to adapt.

If we expect the lifecycle of these pools to be rather bounded I guess this is fine, as it's the simplest / cheapest approach.

[jubeira]

Also let's add a getter here.

[EndymionJkb]

The other reason is Daniel said we did want to support at least two from launch: basic and batch. If we have the registry (see PR #1296), we could use that. It would be equivalent to gerrg's original "provider" idea, and the maintenance would be done in the registry, so we wouldn't need to worry about it here. (And then we don't need a getter.)

[EndymionJkb]

It would look like:

IBalancerContractRegistry private immutable _contractRegistry;

constructor(
    NewPoolParams memory params,
    IVault vault,
    address owner,
    bool swapEnabledOnStart,
    IBalancerContractRegistry contractRegistry
) WeightedPool(params, vault) Ownable(owner) {
    _contractRegistry = contractRegistry;
}

onBefore hooks:
{
    if (_contractRegistry.isActiveBalancerContract(ContractType.ROUTER, router) == false) {
        revert RouterNotTrusted();
    }

    return IRouterCommon(router).getSender() == owner();
}

[jubeira]

The other reason is Daniel said we did want to support at least two from launch: basic and batch. If we have the registry (see PR #1296), we could use that. It would be equivalent to gerrg's original "provider" idea, and the maintenance would be done in the registry, so we wouldn't need to worry about it here. (And then we don't need a getter.)

Sounds like an overkill really.
The trusted router is only used to add liquidity, and block non-owners from adding liquidity. You can still use any router to swap.

[EndymionJkb]

Right... so really the only benefit would be not having to redeploy if we update the basic router (which should be rare compared to adding a new router or updating something more relay-like such as the CLR router)

[gerrrg]

@jubeira good point that the router only affects liquidity provision. Definitely makes it less of an issue, though I do still think it would be best to allow any "approved" router

For more context, the singular trusted router setup that is in the contract was 100% meant to be a placeholder until there was a router provider/contact registry. Simplifying it to be a single router made it possible for me to get unblocked in the meantime

[jubeira]

thanks, I'll double check.
I think this is a good starting point anyways.

[jubeira]

What about initialize?

[jubeira]

Well initialize doesn't have the router argument, so we can't do the same approach.

But we can create and initialize in the same tx. I'll add a method in the factory.

[EndymionJkb]

Agree with the suggestions; ideally would review and merge the registry, then update this one to use it as a source of trusted routers (or we can add a follow-on PR).

[EndymionJkb]

Looks better now; seems the initialization method is still pending? I suppose we could do both: keep the factory method, and also add the onBeforeInitialize hook and check _trustedRouter.getSender() in it.

[EndymionJkb]

Looks good! I'm sure we'll continue to iterate on this in follow-ons, but I think it's a fine starting point.