Cardano Updates

This patch fixes a bug where results `TVar` was never initialised if all
local root peers were provided with their IP addresses, and thus the
node didn't try to connect to any of its local root peers.

We add `LocalRootPeersResult` to `TestTraceEvent` which is used to track
values committed to the `TVar` which holds local root peers with
resolved dns names.  It is more robust to use `traceTVarIO` than to
relay on `TraceLocalRootPeers` events, as  we can force the latter to be
traced even if there's no dns name to be resolved.  This captures the
case where local root peers contains only IP addresses.

This patch fixes a bug where results `TVar` was never initialised if all
local root peers were provided with their IP addresses, and thus the
node didn't try to connect to any of its local root peers.

We add `LocalRootPeersResult` to `TestTraceEvent` which is used to track
values committed to the `TVar` which holds local root peers with
resolved dns names.  It is more robust to use `traceTVarIO` than to
relay on `TraceLocalRootPeers` events, as  we can force the latter to be
traced even if there's no dns name to be resolved.  This captures the
case where local root peers contains only IP addresses.

3862: Make API error expectations compiler-checkable. r=jonathanknowles a=jonathanknowles

Follow-on from https://github.com/input-output-hk/cardano-wallet/pull/3824 ([ADP-2269](https://input-output.atlassian.net/browse/ADP-2269)).

## Summary

This PR replaces `expectErrorCode`, which creates expectations based on string comparisons, with `expectErrorInfo`, which creates expectations based on `ApiErrorInfo` objects.

This has two advantages:
- expectation expressions can be checked statically by the compiler.
- it's possible to express richer expectations based on internal fields of errors (not all errors are just simple values -- some have nested records), using combinators provided by `hspec`.

## Context

In our test suite we test at least two kinds of mapping:

- The mapping between API types and their serialised JSON representations: for all API types, the JSON encoding should be consistent with the OpenAPI specification, and the round trip property `(decode . encode == id)` should hold for all values.
- The mapping from (API call, inputs, state) to API response values: i.e, that API calls return the responses we expect, given appropriate inputs and the current (implicit) wallet state.

Up until now, the approach we've used in `cardano-wallet` is to separate the above two concerns into **different test suites**, i.e., to:

- test expectations about our JSON serialisation logic in specialised tests for just that purpose (JSON golden round trip tests and the test suite for the OpenAPI spec).
- within other test suites (such as the integration test suite), **assume** the correctness of our JSON serialisation logic, and express expectations in terms of ordinary (decoded) Haskell values.

API errors have, up until now, been a sort of exception to this separation of concerns, because until recently we didn't have a good way to create structured errors.

But since merging #3557, which provides support for structured errors and the accompanying [decodeErrorInfo](https://github.com/input-output-hk/cardano-wallet/blob/504774f0f08f4ec74fa91106bc004d8e7b97f875/lib/wallet/integration/src/Test/Integration/Framework/DSL.hs#L559) function, we've gradually been converting expectations about API errors to use the same style as we use for ordinary values returned by the API, which is to express expectations in terms of ordinary Haskell expressions, and to avoid writing expectations in terms of hard-coded strings.

For example, for ordinary (non-error) API responses, we typically write expectations like this:
https://github.com/input-output-hk/cardano-wallet/blob/7af6d54d21443146320eab04452eefb75b3d553e/lib/wallet/integration/src/Test/Integration/Scenario/API/Shelley/Transactions.hs#L297-L299

Co-authored-by: Jonathan Knowles <[email protected]>

:shrug:

The module header haddock still had a reference to a function that had
just been moved mentioning the circular module import issues moving it
solved.

This is only really being checked in because a pull and rebase demanded
doing so. It would have been less log pollution if things wouldn't have
been rebased until after various more complete steps had been completed.

The whole data structure wasn't gotten through, but some comments
preparing for haddock, but not shown in it, were left on the cases
of the coproduct that hadn't been completely deciphered yet.