Consider adding `--Xplugin-rocksdb-high-spec-enabled` flag

[dsimog01]

This flag has helped some users to miss less attestations in Besu. We should consider adding it on mainnet and testnet.

[alexpeterson91]

This cannot be default as it requires a certain generation of CPU or higher, as time goes on more and more people will be able to use this but we have a lot of users still running stuff on old hardware they have laying around, and dont have newer CPUs required for this plugin to be enabled by default.

I started work on this like 3 months ago, and for some reason i never made a PR from my branch but i did yesterday and linked it here in #39 this repo and well a LOT of repos right now are not working with GHAs, not sure if it's because the workflows for all repos need to be bumped to checkoutV3 as in #38, or if theres other issues.
But also i can see that theres no issues building the AMD64 build with this version but the CI fails over and over again due to errors with the ARM64 build. This is the first time Besu has given any ARM64 build errors, i added the arch back before Besu was official and I personally wrote this entire repo for goerli with ARM64 as an architecture from day 1, but theres so much going on with Jammy ports causing all kinds of issues in any of the CI logs.
A couple years ago i was working on trying to remove and discourage use of ARM64 entirely since everything was based on Rasp Pis and when the merge came @pablomendezroyo made the right decision to skip dealing with multi-architecture during that crazy code sprint, and post merge there was only 1 EL and one CL that could do ARM64. I've been slowly working on bringing it back where i can for the last year or whatever as @pablomendezroyo had intended us too, and because ARM64 is now a growing server architecture, Apple silicon is ARM64 and according to a report i read recently up to 30% of PCs will be ARM64 within 2-3 years, with an even higher percentage in servers with newer offerings from AMPERE , Apple, and AMD, so we need to try and keep both arch's working for as many packages as possible especially EVM clients

[alexpeterson91]

also my solution struggles because with the way the stakersUI setup works. You never see the setup wizard for the EL to select true or false from a dropdown. same for sync methods, we need a way to still use the setup wizards while installing and configuring staker setups. not being able to specify an install location is the worst issue, and is a big deal for users who like Erigon, or run archive nodes but struggle with storage space and need to use external drives or additional drives that arent on the main filesystem. And since most sync methods require a DB wipe to change it sucks to have to install it in stakers then reconfigure it from packages then delete the volume and then let it go again, half the time needing to do the same for the CL since the EL volume is wiped etc.
I think there's a LOT of UX improvements we can make to the staker's UI and several of them are really simple, for example there should be a link on each selected client from each column on each network tab that you can click that brings you right to the package's page, like the logs tab or the config tab so that you don't need to back out to another menu to configure the client or check its status or progress.

[non-fungible-nelson]

this flag is more about RAM - if users have more RAM than 16GB this is fine to enable. If not, avoid. Check out here for info: https://besu.hyperledger.org/en/latest/public-networks/how-to/troubleshoot/performance/