Miner rejects `(get-block-info? miner-address u0)`, causing nonce mismatch for submitting account

[BowTiedRadone]

Describe the bug Deploying a contract with the get-block-info? miner-address u0 code works, but executing it causes the miner to reject it, leading to a TooMuchChaining error on further transactions. While @moodmosaic and I were automating contract deployments and calls, we hit this issue.

Steps To Reproduce

1. Build stacks-core and start the node using the configuration located in stacks-core/testnet/stacks-node/conf/mocknet-miner-conf.toml
2. Save the following contract to a file:

   $ cat ./get-block-info-0.clar
   (define-public (func)
   (ok (get-block-info? miner-address u0))

3. Build the deploy transaction using the blockstack-cli binary:

   $ <BLOCKSTACK_CLI_PATH> publish <PRIVATE_KEY> <FEE_RATE> <NONCE> get-block-info-0 ./get-block-info-0.clar --testnet
   # Output:
   <RAW_TX_HEX>

4. Broadcast the raw transaction hex:

   await axios.post(
   "localhost:20443/v2/transactions", 
   Buffer.from(<RAW_TX_HEX>, "hex"),
   { 
   headers: { 
     "Content-type": "application/octet-stream" 
   } 
   },
   );

5. Build the func contract call using the blockstack-cli binary:

   $ <BLOCKSTACK_CLI_PATH> contract-call <PRIVATE_KEY> <FEE_RATE> <CONTRACT_ADDRESS> get-block-info-0 func --testnet

6. Broadcast the raw transaction hex for the contract call (similar to step 3)

Expected behavior We would expect the function to be picked up by the miner and return a proper response.

Environment (please complete the following information):

• OS: Ubuntu Server 24.04 LS
• Rust version: rustc 1.80.1
• Stacks Core version: release/2.5.0.0.5

Additional context The issue was found while running the mocknet, thanks to @obycode's help. Here's the miner log:

INFO [1724952623.797606] [stackslib/src/chainstate/stacks/miner.rs:550] [main] Problematic transaction would invalidate the block, so dropping from mempool, txid: d930d4e8dbe3480ec3c358a917bb55acccbbdfd0a3839bd02a18a60852958d54, error: Interpreter(Expect("Failed to get block data."))

CC: @wileyj

[obycode]

This transaction is treated as a "problematic" transaction, which means that it will not be included in a block. These kinds of transactions always cause trouble, so should be avoided whenever possible. Instead of treating this as a problematic transaction, it should just result in a None response from get-block-info?. This change would need to be implemented as part of a hard fork.