svm: allow conflicting transactions in entries

[2501babe]

(still under dev, new branch because reimplementing was easier than rebasing on latest changes)

Problem

Summary of Changes

Fixes #

[Huzaifa696]

Hi @2501babe, We met with Andrew at Breakpoint and he mentioned that you are working on SIMD#83 related PRs.

We did a quick review of this PR. I have also pushed a set of PRs to enable SIMD#83 and your work looks very similar to what is done already here PR1 PR2 PR3. Please take a look and I hope you will find them quite useful.

Glad to contribute / help out with SIMD#83 related stuff.

[2501babe]

hi! first off, really appreciate your desire to contribute to SIMD83

i looked through your PR1 code a bit before starting on this, but unfortunately concluded i wasnt able to use your code as-written. the way accounts are handled in svm has a lot of very nasty edge cases, especially since fee-only transactions were added, and i felt like i needed to start from scratch to make sure i had a full understanding of the flow

hoping we might be able to collaborate on the account locking changes, which i expect to be a lot more straightforward. ill review PR2 before i start on that and let you know what i think

[Huzaifa696]

Sure, we'll look forward to discussing PR2. A question about PR3.

It is related to the replay side. According to v2.1.0 release notes ryoqan's unified scheduler path will become default and we know it already implements SIMD#83.

Our PR3 implements implements SIMD#83 in replay for the BlockstoreProcessor path.

Do you know if the BlockstoreProcessor path will also be updated to support SIMD#83?

[2501babe]

i believe the idea is that we want simd83 support for the existing scheduler so that validators can continue to use it if they prefer, as far as i know we arent removing it, and once we start making simd83 blocks, everyone will need to be able to replay them even if they dont produce them. however you might want to double-check with andrew to be sure