svm: remove NativeLoader-owned rent assert

[2501babe]

Problem

TransactionAccountStateInfo::new() contains a debug assert that a writable account is not owned by NativeLoader. this is overly general, as the condition we actually value is that a reserved account key is not writable

Summary of Changes

remove it. we could check against ReservedAccountKeys here instead but this would require pulling it from Bank through svm. since it is only is debug assert and the condition itself is checked in sanitization, this does not seem necessary

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.5%. Comparing base (d16bb56) to head (da6a000).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #9574     +/-   ##
=========================================
- Coverage    82.5%    82.5%   -0.1%     
=========================================
  Files         901      901             
  Lines      323326   323325      -1     
=========================================
- Hits       267033   267018     -15     
- Misses      56293    56307     +14     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mergify]

Backports to the stable branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule.

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.