Make LinkMonitor CLA compatible

[fbac]

• addToWatchList function has to be CL Automation compatible.
• removeFromWatchList function has to properly clear the address from the watchList and set it as not active.
• Contract now has admin and executor roles, so the admin can give permissions to different CLA Upkeeps.
• Roles can be revoked.

[github-actions]

I see that you haven't updated any README files. Would it make sense to do so?

[fbac]

PTAL @RyanRHall, and also please @RensR take a look as the CCIP sme.

[RensR]

Missing a lot of test coverage

[RyanRHall]

I don't think the test changes quite match the functionality changes. Ex I don't see anything in the tests about the executor role? Also some new edge cases were added to addToWatchlist() that should have test cases.

Also, this contract is very CCIP specific. I think you might want to either (A) make a copy of the original LinkAvailableBalanceMonitor contract or (B) rename this to something like CCIPOnRampBalanceMonitor or similar. I think preference for (A) as iirc this contract was supposed to serve any contract that implements the linkAvailableForPayment() function (ex VRF) but these changes only make sense for CCIP.

[fbac]

I don't think the test changes quite match the functionality changes. Ex I don't see anything in the tests about the executor role? Also some new edge cases were added to addToWatchlist() that should have test cases.

Also, this contract is very CCIP specific. I think you might want to either (A) make a copy of the original LinkAvailableBalanceMonitor contract or (B) rename this to something like CCIPOnRampBalanceMonitor or similar. I think preference for (A) as iirc this contract was supposed to serve any contract that implements the linkAvailableForPayment() function (ex VRF) but these changes only make sense for CCIP.

Working on the unit tests, I'll add them asap.

Regarding the CCIP specific part, I agree. The idea here is this contract will watch over every kind of contract (vrf, data feed proxies..) but also over CCIP onRamps, and in this last case it will be triggered automatically through the onRampSet event (using Automation). So that's why some of the logic has to be changed while it's still capable of dealing with any other contract type.
Another solution is to create a middleman contract that manages the s_onRamp list and triggers an addition on this contract's watchlist if everything is ok. It would increase the attack surface though.
What do you think?

[cl-sonarqube-production]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication