Remove SVM dependency on agave-feature-set

[pgarg66]

Problem

SVM and runtime currently depends on agave-feature-set. Not all of the features are relevant for SVM. Also, this is causing a tight dependency between SVM and monorepo. It'll be ideal if the SVM features could be configured when SVM is instantiated.

Summary of Changes

Add a new config struct in SVM, that gets initialized/configured as part of SVM instantiation.

Fixes #

[mergify]

If this PR represents a change to the public RPC API:

1. Make sure it includes a complementary update to rpc-client/ (example)
2. Open a follow-up PR to update the JavaScript client @solana/web3.js (example)

Thank you for keeping the RPC clients in sync with the server API @pgarg66.

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 96.15385% with 14 lines in your changes missing coverage. Please review.

Project coverage is 83.0%. Comparing base (7bb8e2d) to head (7281edb).
Report is 8 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #5841    +/-   ##
========================================
  Coverage    83.0%    83.0%            
========================================
  Files         828      829     +1     
  Lines      375826   375994   +168     
========================================
+ Hits       311963   312246   +283     
+ Misses      63863    63748   -115     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[buffalojoec]

Nice work! Overall, I think the concept of a separate feature set for SVM over a callback is a very nice change. Let's see if we can just tidy it up a bit and reduce bloat.

[buffalojoec]

Any chance we can take this opportunity to get rid of the Arc? I can't think of anywhere we actually need a thread-safe atomic reference to a set of Option<Slot>. The feature set should be frozen from the time SVM is instantiated to to the time it's torn down.

[pgarg66]

I was keeping this change for a follow on PR, as it'll increase the size of this PR. Let me see how much additional changes it'll cause. If it's reasonable, I will update it here.

[buffalojoec]

Ok, follow-up PR is also okay, but I definitely think we should take the opportunity to eliminate it while our attention is here.

[LucasSte]

This seems like a lot of repeated code. Do you think we can abstract this initialization in a macro? The struct members are named the same as the features.

[pgarg66]

It'll remove the possibility of naming the feature ID with a different name than what we call in SVM repo. It's easier to call it the same since the features already exist. But, when SVM is a separate repo, it might be extra work to enforce it.

We can probably add a macro in a separate PR, so if we don't like the rigidity in the future we can just revert that PR.

[pgarg66]

Hey @yihau, could you please reserve solana-svm-feature-set crate (newly created in this PR)?