Revert "Make RPC server functions that read db thread safe"

[j-berman]

Reverts PR #7937. Related to #8383.

Incorrect sequence that PR #7937 introduces:

1. db write to add block to chain begins
2. notification that block added to chain is pushed out to consumer
3. consumer makes request to RPC API expecting latest chain state in response
4. RPC server grabs db read txn guard [PR 7937]
5. db write from step 1 completes
6. consumer of RPC API receives consistent but stale view of the chain from before the most recent block was added thanks to the db read txn guard from step 4 [PR 7937]

This PR removes db read txn guards added in #7937 to the RPC server to avoid the above problem, accepting that the RPC API can still possibly return inconsistent data as the lesser of 2 evils (which is current behavior).

A stronger long term fix to ensure consistent chain state reads for RPC functions that will still return the latest data is preferred, with care to ensure a consistently ordered API across all sources (RPC / ZMQ / notifications etc.). See one such proposed solution here. (edited to clear up imprecise explanation)

[selsta]

Correctly reverts PR 7937

[jeffro256]

Correctly reverts #7937, and I think the old behavior is less bad than current behavior