[PASSED] OP-PIP-71: Entropy v2 Testnet Upgrade

## Summary Currently, the Entropy keeper cannot invoke a callback if the unde…rlying callback fails. This creates confusion for users, who can't distinguish between "the keeper is offline" and "my callback code reverts". This change creates a failure flow for callbacks that allows the keeper's transaction to succeed while explicitly reporting a failure of the underlying callback. Requests with failing callbacks remain on the blockchain and can be re-invoked by users. This feature allows users to gracefully recover in cases where the callback fails for transient reasons. (In the future, it will also allow recovery in the case where the callback uses too much gas.) Note that this PR doesn't cover the case where the callback uses too much gas. I will send a follow-up PR for that. ## How has this been tested? - [x] Current tests cover my changes - [x] Added new tests - [ ] Manually tested the code

## Summary Follow up to the last PR around allowing providers to mark on-chai…n callbacks as failed. The previous PR covers cases where the contract manually reverts. This PR covers the case where the callback runs out of gas. This PR gives each callback a gas limit which is stored in the on-chain struct. Providers can set a default gas limit, or users can manually specify a different gas limit when making a request. We mark callbacks as failed if they revert with an out-of-gas error *and* the transaction had enough gas to forward -- there are some EVM nuances here that we need to be careful about. See inline comments for details. ## Rationale Explicitly marking on-chain requests as failed will make the state transitions of entropy much clearer to end users. ## How has this been tested? - [x] Current tests cover my changes - [x] Added new tests - [ ] Manually tested the code

## Summary Bring back the original EntropyStructs definitions and move the ne…w structs to EntropyStructsV2. Use the old EntropyStructs in events to maintain the selectors. ## Rationale The last few Entropy PRs have added fields to the contract structs, which were backward compatible with the storage. However, these changes change the selectors of Events, which breaks the public interface of the contract that is used by Fortuna to identify requests. This PR fixes the public interface so the selectors aren't changed. ## How has this been tested? - [ ] Current tests cover my changes - [ ] Added new tests - [x] Manually tested the code I checked out an old version of the code and computed selectors using `forge selectors list` then compared with the new version.

## Summary As the description says -- it turns out that you can't decode the …old struct data with the new struct format. This restores the old method signatures and adds new methods for retrieving the new versions of the structs. I don't love that we have new methods here for retrieving requests / providers, but that's the only way I see to ensure that all users of the contract continue working. ## How has this been tested? - [x] Current tests cover my changes - [ ] Added new tests - [x] Manually tested the code I tested getting both a request and a provider from an old contract.

## Summary Add a new set of EntropyEvents to improve on the previous spec. Sp…ecifically, add indexing for the salient attributes, stop depending on struct definitions (which, if changed, break the event signature), and add dummy bytes for future extensibility. In the process, I have omitted events for code paths that we are going to kill off (like the old pull flow). ## How has this been tested? - [x] Current tests cover my changes - [x] Added new tests - [ ] Manually tested the code

## Summary As the PR title says ## Rationale Showing the gas limit and …usage will be useful for users to see if their callback is using too much gas, and also to adjust their usage. ## How has this been tested? - [x] Current tests cover my changes - [x] Added new tests - [ ] Manually tested the code

## Summary Update the expectEmit calls to test all topics and data. These wer…e previously only testing the data field. This is going to conflict with the other outstanding PR but I'll resolve that depending on which gets approved first. ## How has this been tested? - [ ] Current tests cover my changes - [ ] Added new tests - [ ] Manually tested the code

## Summary Add a set of `requestV2` methods that give callers optionality on …specifying providers etc. I think we get a set of questions like "what's a provider" or "what's userRandomNumber" which originate from the confusing function signatures in the user interface. I'm not sure why we didn't do this in the first place -- i think for some reason we thought we couldn't override method names. It works though so I think we go for it. I think we may want to pull out some of these methods into a separate solidity interface to make it easier for users of entropy to see the methods they want to call as well. If you're onboard with the interface changes, then I can do that next. ## Rationale This should make it easier for developers to use entropy -- just call `requestV2()` and get a callback. ## How has this been tested? - [ ] Current tests cover my changes - [ ] Added new tests - [ ] Manually tested the code

## Summary Split out the V2 functionality into a separate file. The intention… is that developers can interact exclusively with the IEntropyV2 interface. This interface hides internal methods for providers etc that users don't need to know about. Meanwhile, we retain the IEntropy interface (which has the old functions + provider functions + inherits the V2 functions) as the full interface the contract implements. ## Rationale These changes should make it easier for users to identify the functionality they need ## How has this been tested? - [ ] Current tests cover my changes - [ ] Added new tests - [ ] Manually tested the code

## Summary As the title says. Track gas usage and emit it in the event. ##… Rationale I previously omitted gas tracking in this recovery flow (which is identical to the old callback flow). However, I realized tracking gas will be useful here -- if a user's callback fails and they recover it, they probably want to know how much gas it used so they can set the gas limit better next time. ## How has this been tested? - [ ] Current tests cover my changes - [ ] Added new tests - [ ] Manually tested the code

## Summary Three minor changes: 1. rename "providerRandomNumber" and "userRa…ndomNumber" to xContribution for clarity. 2. emit these contributions in the new EventsV2 revealed event (so users can generate a retry call in forge from the event, without hitting the fortuna API) 3. update docs around how the protocol works and security assumptions (this was a comment from AR) ## How has this been tested? - [x] Current tests cover my changes - [x] Added new tests - [ ] Manually tested the code

## Summary I'm making this 2.0 to agree with all of our comms around this. I'…m skipping version 1 but whatever. ## Rationale ## How has this been tested? - [ ] Current tests cover my changes - [ ] Added new tests - [ ] Manually tested the code