Define tick related helper test methods

[ryoqun]

Problem

my scheduler thing needs to introduce rather invasive code changes including the BankWithScheduler wrapping, which touches tick registration code.

Summary of Changes

Prepare some helper functions.

extracted from: #33070

[ryoqun]

after very loong thought since hacking on dcou, i've finally decided to regard solana-ledger-tool as rather development tool, although it's sometimes used in the production environment indeed (like create-snapshot).

it contains very dangerous code, which i'd like to guard under dcou. for one, the touched code in this pr is literally arbitrarily mangling snapshot with new bank...

so, i think it's okay to blacklist it here.

[apfitzge]

Marking ledger-tool as a tainted package might warrant some wider discussion from ledger-tool focussed people: @steviez @brooksprumo

[steviez]

Thanks for bringing this up apfitzge. I'm not sure I understand the full consequences of adding solana-ledger-tool to this list; can you help me understand the implications of adding solana-ledger-tool here

to regard solana-ledger-tool as rather development tool

I'd mostly agree with this statement, with the caveat that you already mentioned of operators needing this in cluster-restart scenarios.

[ryoqun]

as a quick recap, dcou-ed code (#[cfg(feature = "dev-context-only-utils")]) are much like #[cfg(test)]. those code is used for testing and benching or other development purposes. dcou works across the monorepo workspace, unlike #[cfg(test)]. so, The main benefit of dcou is that dangerous code can safely be shared across monorepo, instead of pub-ing with some for_test suffix and gentleman agreement among engs.

to accomplish the aforementioned goals, dcou-ed code is opt-in only after explicitly enabling the dev-context-only-utils feature. AND, dcou is enforced as a dev-dependency via ci. in this way , any production code (i.e. not test/bench code) can't access dcou code.

dcou was introduced recently as an experiment, but working as intended. so, it's expected to dcou code will increase.

hope the story is straightforward so far. :)

then, there's some fine prints.... sometimes we want exceptions. specifically, we want to protect some code under dcou, while still allowing to be used outside dev-dep.

I'm not sure I understand the full consequences of adding solana-ledger-tool to this list; can you help me understand the implications of adding solana-ledger-tool here

solana-ledger-tool is the exceptional case as being a dev tool. and, adding solana-ledger-tool here means the crate is now one of the exceptions. thus, solana-ledger-tool' s production code will remain to be able to call dcou-ed api without restriction, even after dcou usage is increased.

using this pr as an example, i think tainting it is okay instead of not dcou-ing the .register_unique_tick() just for solana-ledger-tool.

that's because there will be more similar situations, considering the nature of solana-ledger-tool, although it is indeed used for cluster-restart as you mentioned:

to regard solana-ledger-tool as rather development tool

I'd mostly agree with this statement, with the caveat that you already mentioned of operators needing this in cluster-restart scenarios.

on contrast, definitely we want to avoid to add solana-validator and solana (the cli) here.

all in all, I'm saying aggressively protecting solana-validator and the like from some code with dcou outweigh the potential accidental use of dcou code in solana-ledger-tool, which might be a trouble only if it's part of the create-snapshot codepath.

[steviez]

Oops, didn't give my ship-it before you pushed. But in any case ...

hope the story is straightforward so far. :)

Yep, everything up to that point I was aware of

solana-ledger-tool is the exceptional case as being a dev tool. and, adding solana-ledger-tool here means the crate is now one of the exceptions. thus, solana-ledger-tool' s production code will remain to be able to call dcou-ed api without restriction, even after dcou usage is increased

This is what I was unaware of, so thank you for calling it out explicitly!

all in all, I'm saying aggressively protecting solana-validator and the like from some code with dcou outweigh the potential accidental use of dcou code in solana-ledger-tool, which might be a trouble only if it's part of the create-snapshot codepath.

Agree with this sentiment, and while I can't give a retro-active ship it, I'm onboard with the decision / change. Thanks again for the heads up apfitzge & for the explanation ryoqun

[brooksprumo]

Same as ☝️ for me too

[ryoqun]

err, thanks for polite post-merge replies... as i have tons of code to rebase and ship (#33070), i was aggressive in hindsight...

[ryoqun]

dcou with inner attr is kinda cool.

[ryoqun]

_for_test is omitted intentionally due to the use by VoteSimulator and solana-ledger-tool.

[codecov]

Codecov Report

Merging #33537 (7eef3ea) into master (c66af12) will increase coverage by 0.0%.
Report is 4 commits behind head on master.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##           master   #33537   +/-   ##
=======================================
  Coverage    81.7%    81.7%           
=======================================
  Files         805      805           
  Lines      218111   218120    +9     
=======================================
+ Hits       178323   178355   +32     
+ Misses      39788    39765   -23