Script for creating an order for CoWSwap Burner on Sepolia

[elshan-eth]

Description

This PR adds CowSwapBurner and IFeeController. CowSwapBurner will be used as one of the mechanisms for burning fees. Additionally, the PR includes a script for deploying and testing CowSwapBurner on the Sepolia network.

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

[EndymionJkb]

It looks fine, but we have the fundamental decision of whether we're forking or rewriting. The interfaces don't match now (if the feeCollector is supposed to be the sweeper?) The collector in the Vyper contract has a "keeper" fee, deals with epochs and deadlines, and whether a token can be traded: things that seem like they should be the burner's responsibility.

If the collector is the sweeper, the interfaces could be adapted, I guess.

Current sweeper interface:
burn(pool, feeToken, withdrawnTokenBalance, targetToken, _feeRecipient);

Vyper interface:
burn(feeToken[], recipient);

It calls target on the collector, so we could change getTargetToken to just target and accommodate that, so that we don't need to pass that into burn. I suppose it could use the balance instead of having it passed into the burn call, like Vyper does... but what about asynchronous ones where it might have balance from other unsettled trades?

The Vyper contract also doesn't emit any events (which is why I'm passing in the pool address).

Have we decided to fork, in which case we need to try to adapt the sweeper, or can we go the other way and write a new solidity burner that matches the sweeper?