rpcclient: add context.Context support for HTTP POST mode

[seeforschauer]

Change Description

Add context.Context support to rpcclient's HTTP POST mode, allowing callers to cancel or timeout individual RPC calls. Fixes #2499.

Currently, rpcclient methods like GetBlockCount() don't accept a context, which means callers have no way to cancel or set deadlines on individual RPC calls. In HTTP POST mode, handleSendPostMessage uses http.NewRequest without context, and the 10-retry loop doesn't respect external cancellation.

Changes

• Add ctx field to jsonRequest struct
• Use http.NewRequestWithContext in handleSendPostMessage when ctx is set
• Respect context cancellation during retry backoff (select on reqCtx.Done())
• Add SendCmdWithContext(ctx, cmd) to Client
• Add GetBlockCountWithContext(ctx) as the first context-aware method variant
• Existing methods are unchanged — fully backwards compatible

Design decisions

• SendCmdWithContext mirrors SendCmd with an added ctx parameter
• When ctx is nil (e.g., from existing SendCmd callers), context.Background() is used as fallback
• Context cancellation during retry backoff returns immediately instead of waiting for next attempt
• Additional *WithContext methods for other RPC calls can be added incrementally in follow-up PRs

Steps to Test

go test ./rpcclient/ -run TestGetBlockCountWithContext -v
go test ./rpcclient/ -run TestSendCmdWithContext -v
go test ./rpcclient/ -run TestGetBlockCount_Backwards -v

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

• The change is not insubstantial.
• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.

[guibressan]

Diff looks good, tests passing.

Nice work @seeforschauer!

[seeforschauer]

@Roasbeef all four items addressed — mind taking another look when you get a chance?

[kcalvinalvin]

Looks good overall. Some minor test related issues that I saw

[seeforschauer]

@kcalvinalvin pls review

[seeforschauer]

@Roasbeef would you please review once more?

[kcalvinalvin]

I get that these are easy (probably automatic) fixes but it does make reviewing a bit more annoying since I believe all the reviewers read git diffs commit by commit

[kcalvinalvin]

The code looks good. Though the tests aren't doing much.

These test all pass even when the context is dropped in GetBlockCountWithConext:

• TestGetBlockCountWithContextSuccess
• TestGetBlockCountBackwardsCompatible
• TestGetBlockCountWithContextRPCError
• TestHandleSendPostMessageNilCtxFallsBackToBackground

Ran the tests with this code:

[I] calvin@nixos ~/b/b/b/rpcclient ((6e5bb34c)) [1]> git diff
diff --git a/rpcclient/chain.go b/rpcclient/chain.go
index a5cedc64..6381534d 100644
--- a/rpcclient/chain.go
+++ b/rpcclient/chain.go
@@ -301,7 +301,8 @@ func (c *Client) GetBlockCountWithContext(

        cmd := btcjson.NewGetBlockCountCmd()
        return FutureGetBlockCountResult(
-               c.SendCmdWithContext(ctx, cmd),
+               //c.SendCmdWithContext(ctx, cmd),
+               c.SendCmdWithContext(context.Background(), cmd),
        ).Receive()
 }

Like the tests are implementing the handler in the test and is just checking if that works. I don't think that's useful really.

I feel that the actual code is mergeable. The tests... eh.

Another nit is the git commit format. I'd prefer the follow up commits to be amended into the originals. But these aren't a blocker.

[seeforschauer]

updated

[saubyk]

Hi @seeforschauer why is this pr in draft status?

[kcalvinalvin]

The latest commit ccbcd30 fixes the test problems I pointed out. LGTM.

Still not a fan of the commit order but that's not a stopper

[kcalvinalvin]

Looks good