Add looser block deadline in order rewards query

[harisang]

I am tempted to say that there is a bug in the order rewards query. Specifically, it seems that the following case might happen:

• we look at all trades executed between a start_block and an end_block in the trade_hashes table.
• we then pull additional information about these trades, in order to compute protocol fees etc, and these computations start with the order_surplus table. But in that table, which contains information from the settlement_scores table, we ask that the deadline of the settlements we look into is end_block. I think this can cause some information to be lost, because we do a left outer join of the trade_hashes table with everything else, so every trade executed between start_block and end_block will be included in our result, while not all information about these trades will have been recovered, due to the restricted block_deadline. This is because a trade can execute at block x, while its deadline might be up to x+9, i believe.

To address this, we propose to add some very generous buffer in the block_deadline considered, so as to ensure all relevant info about the trades are pulled together and joined in the final table.

Note: this was first noticed when i was trying to fix the integration test for PR #94 , and because of that, I opened issue #95. This PR addresses this issue.

As a final comment, an alternative would be to actually not do the above and try to only use block_deadline, similar to the batch rewards query.

[fhenneke]

The mismatch of block_deadline and block_number is unfortunate.

(edit: looks good after thinking about it a bit more) If we want to go with that fix, would we not have to decrease the staring value? Something like

        ss.block_deadline >= {{start_block}} - 100
        AND ss.block_deadline <= {{end_block}}

We always have block_deadline > block_number and (for valid settlements) block_number > block_deadline - 100.

Alternatively, the query for trade_hashes could contain the block deadline via

        JOIN settlement_scores ss ON s.auction_id = ss.auction_id
    WHERE
        ss.block_deadline > {{start_block}}
        AND ss.block_deadline <= {{end_block}}

similarly to how it is done in batch rewards. Then the query itself would be a bit nicer, but potentially there is a mismatch with double counting after a resync.

[fhenneke]

Looks good.
A comment should be added now or later. There is a slight cleaner design, I think, but we can switch to that later.

[harisang]

ok let's issue a release now with this, and we can revisit it soon as we will probably need some minor changes regarding integrator fees that should be implemented in the next few days.