Add list of batches excluded from slippage computation (due to R depeg)

[fhenneke]

This adds some transaction hashes to the table of batches excluded from slippage computation.
This is done in the Dune query and not in the python code since all computations related to slippage happen on Dune.

Alternative approaches:

• Use different prices for the conversion to ETH, e.g., prices at the time of rewards payment.
• Implement filtering as post-processing in python.

Since we plan to overhaul the slippage computation, we went for the hacky solution.

[harisang]

Can you also do a dry run with this fix so that we are sure it works?

[fhenneke]

Dry run works as expected. ETH transfers from the script are identical to numbers on done dashboard.

[harisang]

This PR just got merged: duneanalytics/spellbook#4776

So I am wondering whether we should remove hashes:

• 0x4b8b031baebd7c13652f51ab33feaec078093c992edcb23c3e9f531fa9310131
• 0xaa037b87eba06781f0699b6c021fa84d67a197502d3141c00c9e274055899118

as they are disjoint from the R stable coin depeg.

[fhenneke]

So I am wondering whether we should remove hashes:
0x4b8b031baebd7c13652f51ab33feaec078093c992edcb23c3e9f531fa9310131
0xaa037b87eba06781f0699b6c021fa84d67a197502d3141c00c9e274055899118
as they are disjoint from the R stable coin depeg.

We should exclude as few auctions as possible. If those settlements are not related to the depeg, they should be removed in my opinion.

[fhenneke]

We did not go for excluding the batches after all. The depeg reasonably falls under inventory risk. The reimburement for the suboptimal settlement by Quasilabs is handled by the solver and not by the protocol.