op-service: RPC call context utils

Idea to maybe radically change our test flakes: instead of retry-ing on the RPC caller layer, we can retry on the RPC layer itself.
And instead of applying a blanket global 10 second timeout across all RPC usage, we can allow modification.

We could generalize RPC things like retries and timeout choices by passing the strategy, not the action, via context.

So not like:
```
ctx = context.WithTimeout(ctx, timeout) // context.Context, time.Duration
```

But more like:
```
fn := func(ctx context.Context) context.Context {
return context.WithTimeout(ctx, timeout)
}
ctx = client.WithTimeoutFn(ctx, fn)`
```
So that the `client` RPC package can then identify the timeout strategy, and apply it.

Services internally, and test DSL (!!!) can be set up with root contexts that have a default timeout and retry strategy.
So all DSL implementations won't have to be wrapping all RPC calls in `retry.DoX` statements anymore, but instead just annotate the context once, with a good test default, for all future interactions.

And when needed, simply by wrapping a new strategy onto the context, calls can be customized when needed (e.g. long-running RPC calls to not time out, or particular retries to happen).

Things I would like to instrument this way:
- timeouts
- retries
- upon any error, or specific RPC error codes
- customize backoff strategy
- customize jitter

Note: logging and metrics are better suited to be applied via the RPC tracer functionality, since they do not modify behavior, and need to inspect the error code and have access to the raw JSON.

No files, tests, or entry points are named. Start by locating the client RPC package and existing retry, timeout, and test DSL call sites. Done would mean a reviewed design and implementation for context-carried timeout and retry strategies, including the listed customization points.

Written by the indexing model from the issue text.