feat: Add --config and --network flags to several stacks-inspect subcommands

[jbencin]

Description

Allow for users to pass either:

• --config <file>
• --network <helium|mainnet|mocknet|xenon>

to the following stacks-inspect subcommands:

• try-mine
• replay-block
• replay-naka-block
• replay-mock-mining

This allows these commands to be used with non-mainnet chainstate. These CLI options must come before the subcommand:

stacks-inspect --config my_config.toml try-mine path/to/chainstate 10 10000

Applicable issues

• fixes #

Additional info (benefits, drawbacks, caveats)

Warning

It was discovered while testing this PR that stacks-inspect try-mine is currently broken and does not work on post-Nakamoto chainstates. For now, I have added an explicit panic when using this command on Nakamoto a chainstate, and I intend to add Nakamoto support in a separate PR

This PR moves config.rs from stacks-node to stackslib in order for the stacks-inspect command to use the same config file as a Stacks node.

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[obycode]

LGTM! This has already proven to be very useful. Thanks 🙌

[wileyj]

The one thing i'd like to know about here is the choice to move the example configs.

was there a specific reason the existing location wouldn't work, or this was an attempt to standardize it more?
if standardizing - maybe we should move the cofigs to the docs folder etc instead.

if we do keep these changes (or decide to use ./docs etc), we'll also want to check downstream if anything is still linking to the current example config location.

but, as @obycode said - this PR has already been incredibly useful, nice work!

[jbencin]

The one thing i'd like to know about here is the choice to move the example configs.

There were unit tests in confg.rs that parsed these config files, and looked them up like this:

let conf_dir: PathBuf = Path::new(env!("CARGO_MANIFEST_DIR")).join("conf");

So this was the simplest way to get the tests passing. If these config files are just unit test fixtures, it makes sense to keep them close to the code. If they are also meant to be examples to users setting up a node, then perhaps they should be elsewhere, like a top-level examples/ directory, or we can symlink to them from stacks-node

[jbencin]

@wileyj I added a symlink from the old example config location to the new one to address your concern. I think this is the best solution because:

• It doesn't break existing links
• Test fixtures should live close to the code
• stackslib should not have dependencies on stacks-node

But I know symlinks can cause issues in some environments, so let me know if this is a problem

[wileyj]

@wileyj I added a symlink from the old example config location to the new one to address your concern. I think this is the best solution because:

• It doesn't break existing links
• Test fixtures should live close to the code
• stackslib should not have dependencies on stacks-node

But I know symlinks can cause issues in some environments, so let me know if this is a problem

i like the symlink idea (but i also like a more standardized location for the example configs, since they are meant for users, not necessarily for tests).
if we symlinked from the current dir to the previous location (and open an issue to standardize the location), would that break your tests?

[jbencin]

if we symlinked from the current dir to the previous location (and open an issue to standardize the location), would that break your tests?

I assume the tests would be fine if stackslib/conf were a symlink. I don't know for sure, but it's easy to test. I don't think the stackslib code should depend on paths outside of stackslib/, but I don't see a problem with solving this at the filesystem layer

[wileyj]

linked to #5575

lgtm!

[jcnelson]

Tested and LGTM, but please address all remaining comments before merging. Thanks for making this change!