Advanced Flow Tests

[mtabasco]

          Please add these test cases:

Multiple bApps using the same token in one strategy
usedTokens[strategyId][token] counts how many distinct bApps use that token.
Confirm that increment/decrement logic is correct if the same strategy owner opts in to multiple different bApps that each accept the same token.

Test Idea:

1. Create a strategy.
2. Register two different bApps (BAPP1, BAPP2), both supporting the same token (e.g. erc20mock).
3. Opt in with (strategyId, BAPP1, erc20mock, nonzero obligation). Then check usedTokens[strategyId][erc20mock] == 1.
4. Opt in to (strategyId, BAPP2, erc20mock, nonzero obligation). Now usedTokens[strategyId][erc20mock] should be 2.
5. Then propose a zero obligation for BAPP1 and finalize it. Check that usedTokens[strategyId][erc20mock] is now 1.
6. Finally, propose a zero obligation for BAPP2. After finalizing, it should be 0.
7. Confirm that after it’s fully zero, you can fastWithdrawERC20.

---

Edge case: Repeated 0→nonzero updates in 1 tx

_updateObligation increments usedTokens if old was 0 and new is > 0.
Check no double‐increment if a user in the same transaction tries to do multiple calls.

Test idea:

1. Start with an obligation of 0.
2. In a single vm.startPrank(USER1) context, call fastUpdateObligation from 0→X.
3. Do another call to fastUpdateObligation again from X→Y, still in the same transaction.

Expected result:
The second call is also an “increase,” so it should not break anything. Check if usedTokens increments only once (from 0→X) and not again from X→Y.
This requires a special test in Foundry that doesn’t rely on multiple separate tests but tries consecutive calls in one block.

---

Multiple participants in the same strategy (this maybe its checked by different tests currently)
Confirm each strategy participant can do a fast or timed withdrawal independently.

Test idea:

1. STRATEGY1 is created by USER1.
2. USER2 deposits ERC20 into STRATEGY1.
3. If no obligations are set, USER2 can do fastWithdrawERC20. USER2 can remove its own funds even though they’re not the strategy owner.
4. Then the strategy owner sets an obligation. Confirm now USER2 must make a timelocked withdrawal.
   This ensures that participants can deposit/withdraw from a strategy they don’t own, and that timelock logic is enforced properly for them.

Originally posted by @mtabasco in #4 (comment)