Fix NFT race condition

[pmantica11]

Summary

Context:

1. The assets table is a denormalized of data derived from token, mint and metadata accounts. Each of the different kinds of accounts updates a particular subset of columns within the assets table.
2. The NFT ingester makes no guarantees to the order of how account updates are processed. So to prevent earlier updates from overriding later ones we store in all tables the slot_updated column and when processing an account only update the table if the slot is greater than or equal to the current slot_updated of the table.

Issue:
The fundamental issue is that even though the assets table holds denormalized data for 3 different kind of account updates, it only has one slot_updated column. This means that, for instance, token accounts updates get ignored if a metadata account processed with a greater slot was already processed. This is clearly erroneous because the token account update and metadata affect different columns. So metadata account updates should in no way interfere from token account data being updated. For instance, in this case the owner column, which is updated through token account updates, doesn’t get properly updated and reflects stale ownership data.

Solution:
Added slot_updated_mint_account, slot_updated_token_account and slot_updated_metadata_account columns to avoid metadata/token/mint updates from interfering with each other. Also added helper functions to make sure that in each account update we only modify the columns that each account is responsible for.

One issue that I had to deal with is we use the slot_updated column for sorting. So I created a db trigger so that it's always the max of the slot_updated columns. I also created a slot_updated_cnft_transaction so that we keep track of cNFT slot updates.

Tests

Ran new integration tests and added an account_updates_tests.rs file that tests the race condition alongside general update logic.

[kespinola]

Using the additional slot columns is a good way to manage updates to the asset table given its a compilation of the metadata, token, cnft, and ta accounts. I do believe tthese updates will likely reduce the ingestion rate (see other comments) but is still worth releasing to improve data correctness.

I will be follow up with an issue for us to discuss the pros/cons of normalizing the asset so there are no dependencies between the accounts in question. It requires more joins on the read side so there are draw backs but this logic is complicated and intensive. I believe correctness should be the number one concern for project so I'm personally willing to take a hit on the query for clearer ingestion flow. We can introduce conventional caching technics for the reads to keep them fast. Anyhow look for the issue we can talk more there.

I am blocking to encourage discussion about the use of a trigger. I do also encourage the changes to the migration.

I'm chatting with the Triton team to get this tested because we too have been experiencing issues related to ownership updates for traditional nfts which this addresses. Thank you 👍