Eliminate some obviously useless threading

[alexpyattaev]

Problem

pub fn ed25519_verify_disabled(batches: &mut [PacketBatch]) in perf/src/sigverify.rs
does pretty much no work (sets a boolean flag for each Packet in PacketBatch) and yet it creates doubly nested parallel iterators to achieve this results. It further does this on rayon's global thread pool so it is impossible to do accounting on this activity.

Summary of Changes

Changed the function to set the flags in single flattened iterator using appropriate pool, this also matches the behavior of ed25519_verify for consistency.

[steviez]

Hi @alexpyattaev - The PR description and code changes don't match; the problem description refers to sigverify but the actual diff is touching rocksdb.

Ignoring that and responding to the rocksdb changes, I still think wiring things up to be configurable (on the CLI for now since that is where everything else is) is the right move for now to allow some customization & leave an escape hatch for later.

I have #4214 which does that; I opened this a couple days ago but didn't add reviewers and/or draw attention to it in light of the holidays. I think our efforts were mostly tangential here, but we can make sure to coordinate better in Slack to avoid any duplicated efforts moving forwards

[alexpyattaev]

Sorry I have pushed the wrong diff. Should not make PRs late at night. Especially the "small and trivial" ones.

[steviez]

Unless there are several thousands of packets in those batches, this will be faster.

I'm not sure if this function can actually get called in production, but if you look at SigverifyStage, 1000's of packets is not completely unexpected

agave/core/src/sigverify_stage.rs

Lines 35 to 36 in e3f99e6

	// 50ms/(10us/packet) = 5000 packets
	const MAX_SIGVERIFY_BATCH: usize = 5_000;

[alexpyattaev]

I guess the whole point was to save resources by skipping verify in some debug/devel runs. I guess if we are dealing with truly huge numbers of packets parallelizing it may still be wise. Changed to act same as the "real" version, which works without nested parallel iterators.

[steviez]

Changed to act same as the "real" version, which works without nested parallel iterators.

Yeah, this seems like a reasonable change; make it somewhat match the real one. Would you mind updating the problem description / summary of changes to more accurately reflect the new change ? I know this is a fairly minor change, but I think it is nice to have PR descriptions match the underlying code change incase we're bisecting or doing something else that involves looking through history

[steviez]

LGTM