Feat/miner hot reload

[rob-stacks]

Description

This patch adds a hot-reload option for miners to allow automatically re-applying configurations (even in the middle of a tenure) when the config file changes.

Applicable issues

• fixes #

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• For new Clarity features or consensus changes, add property tests (see docs/property-testing.md)
• Changelog is updated
• Required documentation changes (e.g., rpc/openapi.yaml for RPC endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo

[benjamin-stacks]

I don't yet have the full mental model of the lifetimes of the various components, but when I search for references to Config::miner, I'm finding a bunch of things that seem to live outside the miner thread, and that involve clones of the config (or parts of it) that won't see changes made in the miner thread.

For example, in StacksNode::spawn():

stacks-core/stacks-node/src/nakamoto_node.rs

Lines 188 to 190 in 220840e

	if let Some(mining_key) = config.miner.mining_key.clone() {
	keychain.set_nakamoto_sk(mining_key);
	}

or in the relayer, whose config is cloned at the time of spawning the miner:

stacks-core/stacks-node/src/nakamoto_node/relayer.rs

Line 554 in 220840e

|| !self.config.miner.wait_for_block_download

How are we ensuring that we don't end up with inconsistent configurations across components if only the BlockMinerThread updates its own MinerConfig instance? And probably more importantly, how can we ensure that that always remains the case?

[jcnelson]

LGTM, but please use the new changelog system. Thanks!

[dhaney-stacks]

@rob-stacks please merge soon