Use bonsai code cache in ExtCodeSizeOperation

[daniellehrner]

PR description

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[daniellehrner]

I am currently unsure if Forest accounts would benefit from evm.getOrCreateCachedJumpDest(). The old logic is a bit confusing, as we first get the code bytes from the state before checking the cache

[daniellehrner]

It seems the code size is already cached because the byte instance has the size already calculated when the object is created