Use inner joins instead of left joins on transactions

[aalan3]

This fixes a bug that I introduced with the performance fixes.

On incremental runs we still select all of the decoded data in some cases. When we then left join instead of inner join the data that is more than 1 week old will have empty transaction data. To fix this we should use inner join. This should not be a problem because all decoded data has a transaction.

In the cases where we already filter decoded data on where evt_block_time >= (select max(block_time) from {{ this }}) for incremental runs, this should not have caused any issue. But for opensea which doesn't have that for example it did.

If we still have to do a left join like we seemingly do on opensea fees, we can add the filter in the where statement as well to make sure we don't get any extra data.

Looksrare doesn't have this problem because it already uses an inner join.

I've verified the following:

• Opensea inner join vs left join count is the same
• Opensea join on fees needs to be left join so added a where statement as well
• Opensea no null values for block_time
• Opensea incremental update contains no null values for block_time like before
• x2y2 inner join vs left join count is the same
• seaport inner join vs left join count is the same
• sudoswap inner join vs left join count is the same for join on transactions
• sudoswap inner join vs left join count is the same for join on traces

[jeff-dude]

fyi @springzh on comments in description here related to opensea block_time values

[soispoke]

@aalan3 @jeff-dude I've run more tests on the opensea spell to make sure underlying data wasn't modified for some reason, and everything looks good !
I've also added an incremental filter on wyvern_call_data, and this seems to lead to a performance increase in update time (now only takes 55 seconds compared to 200 seconds previously on a dedicated cluster). We'll have to monitor on prod but looks promising !