Sequential commit

[zajck]

This PR introduces sequential commit into the protocol.
It also includes methods used for price discovery, since it's needed for tests (fulFilOrder, fulfilBuyOrder and fulfilSellOrder). This might not be in its final form and might be completely replaced, since at the end we expect to have the same price discovery methods shared between commitToOffer and sequentialCommitToOffer.

Changes:

• added structs SequentialCommit and PriceDiscovery
• added IBosonSequentialCommitHandler.sol which implements IERC721Receiver interface and has additional method sequentialCommitToOffer
• added mock contract that acts as price discovery contract
• created a PriceDiscoveryBase which:
  • handles WETH <> native token management
  • added price discovery internal methods fulFilOrder, fulfilBuyOrder and fulfilSellOrder
• created SequentialCommitFacet with methods
  • sequentialCommitToOffer to handle sequential commits
  • onERC721Received to handle incoming boson vouchers
• in contracts/protocol/facets/ExchangeHandlerFacet.sol
  • nonReentrant modifier was removed from onVoucherTransferred
• in contracts/protocol/libs/FundsLib.sol
  • added releaseFundsToIntermediateSellers to handle funds at finalization time for all involved parties
  • refactored part of the code by adding increaseAvailableFundsAndEmitEvent
  • changed transferFundsToProtocol and transferFundsFromProtocol so they can work without _entityId
• changed deploy script to support deployment of handlers with constructors

Note: this implementation works with the current royalties (one recipient, one percentage). Royalties will be changed in a separate PR and after it's approved, sequential commit will be adapted to work with them.

Removal of reentrancy guard on onVoucherTransferred

Reentrancy guard on onVoucherTransferred prevents voucher transfer during the sequential commit, therefore it was removed. It does not pose a threat to the protocol or vouchers, since it does not make any external calls and it's callable only by voucher contracts, which are under our control. The only reason why we had it here before was to prevent potential inconsistencies in the last field of VoucherTransferred. In an edge case scenario, executedBy can be incorrect - this happens if address1 submits metatransaction to redeem a voucher for offer with twins. If then of the twins executes a boson voucher transfer, onVoucherTransferred will still show address1 as executor and not twin contract address.
This is unlikely scenario with no real threat.
There are two alternative approaches that would allow keeping reentrancy guard on onVoucherTransferred. One is to modify vouchers to not invoke onVoucherTransferred when _to is protocol contract, but that would also require to modify transferFrom to not allow unsafe transfers to protocol. Another way would be to modify reentracy guard for this specific case, so it would allow 1 reenter during sequential commit and only to onVoucherTransferred.
However, both approaches are more complex.

[levalleux-ludo]

Lots of questions (informative) + a few remarks.
The most important one is about taking into account the offer collection to retrieve the voucher contract

[levalleux-ludo]

idem above line 92

[zajck]

Fixed.

[coveralls]

coverage: 98.86% (-0.7%) from 99.559%
when pulling bc18cc3 on sequential-commit-2
into 9cc931b on main.

[github-advanced-security]

Slither found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.