feat: implement airstreams with lockup dynamic

[smol-ninja]

Closes #274.

Summary

1. To create LD campaign.

function createMerkleLockupLD(baseParams, lockupDynamic, ipfsCID, aggregateAmount, recipientsCount)
    external returns (merkleLockupLD);

2. To claim Airdrop from an LD campaign.

function claim(index, recipient, amount, segments, merkleProof)
    external returns (streamId);

3. Adds a new event.

event CreateMerkleLockupLD(merkleLockupLD, baseParams, lockupDynamic, ipfsCID, aggregateAmount, recipientsCount);

• Integrations tests for MerkleLockupLD
• Fork tests for MerkleLockupLD

Security consideration

If protocol fee is not zero, claiming will fail. When protocol fee is non-zero, amount in claim() must include the protocol fee.

[andreivladbrg]

Let's add an amount parameter in the claim function regardless we remove the protocol fee or not. It would save us gas if we do so

[smol-ninja]

Yeah. I agree with that.

[andreivladbrg]

Great work, Shub!

I'll leave these comments for now (might find more things later), so we can keep things moving

[andreivladbrg]

let's include amount in the leaf

so that the leaf is the same as LL + segments. it would make things easier for merkle-api (i think)

[smol-ninja]

makes sense. I have changed it to

bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(index, recipient, amount, segments))));

[smol-ninja]

@andreivladbrg reopening this conversation because I disagree that we should include amount in the leaf.

When the protocol fee is non-zero, constructing Merkle tree would require the UI to reverse calculate all the claim amounts to include the protocol fee.

Consider the below simple example

1. Segments sum to 10,000 for each user.
2. If protocol fee = 1%, UI would have to reverse calculate the amount as 10,000/0.9 = 11111 and include it in the Merkle tree.
3. When a user claims, 11111*0.9 must match the segments sum otherwise claim would fail. Now because step 2 requires division in the UI, it is exposed to floating point errors leading to users not being able to claim (since we have strict equality depositAmount != segmentAmountsSum). This may require re-submitting the Merkle tree.

So it is safe to not include amount in the Merkle leaf and let it be an input parameter into the claim function.

[andreivladbrg]

you are correct

i will create a separate discussion regarding what to include in the Merkle tree because Mircea told me that there are some considerations we have to take into account

[smol-ninja]

Great feedbacks @andreivladbrg and thank you for the review.

[andreivladbrg]

Until we make a decision regarding this discussion, I suggest we put this PR on hold.

[smol-ninja]

I will fix the merge conflicts after we have made this decision.

[smol-ninja]

Closing it as discussed in #288.