test: AztecRPC API using sandbox

[benesjan]

1. Fixes #1504
2. propagates actual error thrown on the server to the JsonRpcClient (instead of showing the generic Bad Request one).

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[spalladino]

Looks good! I believe there are two changes needed though.

[spalladino]

I don't think this belongs here: retry is a generic util, used in many different contexts, not just json-rpc client/server. It shouldn't know about this particular cause. I think the clean version to do it is either:

1. Include another optional param that takes an error and returns a bool on whether to abort retries or not
2. Have the function fn receive a parameter that can be used to bail, similar to how async-retry does it
3. Have fn wrap its non-retriable exceptions in a specific NoRetryException
4. Or have fn attach a retry: false property to the exception to avoid retries

[benesjan]

You have a good point. I think that given our specific use case, which is "forward all the errors to the client if the error was actually thrown by the server code", option 1 is too impractical (I want all the server thrown errors to be bubbled up so listing them all is too verbose) and option 2 is in my opinion unnecessarily generic (I don't need to do anything special with different errors, I just want it to not retry on server-thrown errors).

For this reason I think option 3 or 4 are the way to go.

I think option 3 will result in a more readable code so I will go with it.

Thank you for for laying out the options so thoroughly.

Addressed in e1d40d9.