Provide a way to validate addresses via the API.

[KtorZ]

Context

Exchanges prefer validating data before submission (even though the API will validate things upon submission). There's no easy to simply validate arbitrary string an know whether they are valid addresses or not. That feature exists in cardano-address but only available via command-line.

Decision

Make the API able to inspect addresses.

Acceptance Criteria

1. There's a new API endpoint to validate addresses
2. The validation is implemented using cardano-address 'inspect' method.

---

Development

• Added endpoint to the API ==> Allow address inspection via the API #2184
• Tweaked a bit the swagger documentation to put the endpoint in a separate category ==> Make addresses separate category in swagger #2185

QA

• The inspect feature comes from cardano-addresses and is well-tested there.

• Added two straightforward integration tests showing that the API reacts correctly to inputs:

  https://github.com/input-output-hk/cardano-wallet/blob/d4d5cf3f1dbf478e49186f9e1742939af528bcaa/lib/core-integration/src/Test/Integration/Scenario/API/Shelley/Addresses.hs#L229-L237

• Make sure that the generated JSON matches the OpenAPI schema:

  https://github.com/input-output-hk/cardano-wallet/blob/d4d5cf3f1dbf478e49186f9e1742939af528bcaa/lib/core/test/unit/Cardano/Wallet/Api/TypesSpec.hs#L1524-L1525

  Although, this is a bit of a lie because we don't yet have a proper type to represent the result of an address inspection. What we get from cardano-addresses is an opaque JSON value which (from a type perspective) could be anything. So we should ultimately replace this with a proper Haskell data-type so that we can have static type-checking on this:

  https://github.com/input-output-hk/cardano-wallet/blob/d4d5cf3f1dbf478e49186f9e1742939af528bcaa/lib/core/test/unit/Cardano/Wallet/Api/TypesSpec.hs#L1460-L1467

• Ported the test cases from cardano-addresses and tested them at the unit-level. Ideally, once we have cardano-addresses to return a proper Haskell data-type, we can make the test a bit more expressive instead of simply isRight and isLeft

  https://github.com/input-output-hk/cardano-wallet/blob/d4d5cf3f1dbf478e49186f9e1742939af528bcaa/lib/shelley/test/unit/Cardano/Wallet/Shelley/CompatibilitySpec.hs#L232-L292

[piotr-iohk]

Lgtm. However I wonder if there is a point of showing network_tag: null in case of Mainnet/Staging Byron random and Byron icarus addresses. Perhaps better not to show anything?

curl http://localhost:8092/v2/addresses/DdzFFzCqrhtBfCivoJApi19mydJT1ipghz72mqPPzmZZ1ULYxronKfB4HCYfXGoxEsvgsBKuTeF7ZAi2VytAA78sBT1EpXLk4CgoJQTK 
{
  "stake_reference": "none",
  "address_style": "Byron",
  "address_root": "f3ab6fc64a78c8b4873002c578dee136c062d340358b973a4be6dfbb",
  "derivation_path": "581cc17572ba517c7d2b68b598478ac15aedbb49a0bdfc960d33fb56d0fe",
  "network_tag": null <--------------------
}

curl http://localhost:8092/v2/addresses/Ae2tdPwUPEZCXHQ1b2RjVryp63eVAehJN4HPPYGH1fuddixeQRkzERCbEB6 

{
  "stake_reference": "none",
  "address_style": "Icarus",
  "address_root": "9d8157c18118e753486e3fc39754b2772aa187e5241a5e1a6d2f5b0f",
  "network_tag": null <--------------------
}

[KtorZ]

It'd rather be explicit about that one and show it. It's not that the information is not available (in which case not showing the key would make more sense), it's that, we know that there's no network tag. So that's a bit different and a null value is better suited for this IMO.