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.

[Roasbeef]

Alternatively, we could update all the methods to accept a context param, but via a functional option. This would break any interfaces created off the client, be direct callers would still compile.

[Roasbeef]

That would be a larger diff tho, so perhaps we'll land this one extension for now, then return to this later.

[seeforschauer]

Like this direction a lot — CallOption would avoid the WithContext method explosion across 100+ methods and is extensible for future options. Happy to do it as a follow-up PR once this one lands.

[Roasbeef]

We could camel case everywhere, including tests.

[seeforschauer]

Done — all test names use camelCase now.

[Roasbeef]

This duplicates SendCmd, let's refactor such that SendCmdWithContext can just call `SendCmd, but pass in the context from the user.

[seeforschauer]

Done — SendCmd now delegates to SendCmdWithContext(context.Background(), cmd). Single implementation.

[Roasbeef]

Above when we call c.httpClient.Do(httpReq), we should check the context error, as perhaps we should bail right there instead of retrying again.

[seeforschauer]

Done — added reqCtx.Err() check right after httpClient.Do. If context is cancelled, we bail out immediately instead of entering the backoff/retry path.