chore: add unique constraint on vm_messages.params

[kasteph]

Stacks on: #1105 (please review #1105 first before this one)
Resolves: #1106

To prevent duplicate vm_messages, we can add a constraint on the params.

[placer14]

Two thoughts:

Functionally: Could this constraint be reduced to fewer columns? The likelihood of a (state_root, cid) collision is practically non-existent (since the hash for the cid depends on the state_root hash). With this in hand, could we safely remove the source from the constraint to make insertion a little cheaper?

Overall: I'm also not sure how these duplicates are being introduced? Do the duplicate internal messages (with the same params) actually occur at the same (height, state_root, cid, source) combinations? (The issue is vague on the cause of this problem.) Do we know why this is? Are they important to capture?

The best I can think is that the VM runs certain state changes over and over by virtue of the source message being included in multiple blocks within a single tipset. If this is the case, then the param unique constraint doesn't add anything as the CID would match (because params change the message CID, correct?).

I think a clearer explanation of how this fixes the problem would be helpful.

[kasteph]

Functionally: Could this constraint be reduced to fewer columns? The likelihood of a (state_root, cid) collision is practically non-existent (since the hash for the cid depends on the state_root hash). With this in hand, could we safely remove the source from the constraint to make insertion a little cheaper?

That sounds good.

Overall: I'm also not sure how these duplicates are being introduced? Do the duplicate internal messages (with the same params) actually occur at the same (height, state_root, cid, source) combinations? (The issue is vague on the cause of this problem.) Do we know why this is? Are they important to capture?

Forrest commented on Slack:

Duplicates here are again an artifact of the table schema. There is no requirement that these messages are unique since they do not appear on chain. It is likely that case that these parameters are different for each of the duplicate messages.

[frrist]

We need to hold on this change until more details are added to #1106. I don't have a clear picture of what problem we are trying to fix here - I actually don't see a problem.

[frrist]

closing in favor of #1127