Create compatibility QA tests for purchasing between v4 and v5 nodes

[drwasho]

With the Ethereum update, we've taken a lot of measure to ensure that v4 (legacy) and v5 (upgraded 'eth-compatible') nodes can transact. We need to ensure that these interactions will proceed without error; note that this only affects UTXO purchases as v5 nodes cannot purchase listings with ETH from v4 nodes.

The best way to do this is to create some dedicated compatibility QA tests where:

The buyer is a v4 node and the seller is a v5 node

• 1. cancel direct offline | blah |
• 2. complete direct online
• 3. complete disputed
• 4. complete moderated online
• 5. complete moderated with timeout
• 6. dispute close buyer
• 7. dispute close split
• 8. dispute close vendor
• 9. escrow release after timeout
• 10. fulfill direct online
• 11. market price modifier
• 12. out of inventory
• 13. purchase crypto listing
• 14. purchase digital
• 15. purchase direct offline
• 16. purchase direct online
• 17. purchase moderated offline
• 18. purchase moderated online
• 19. purchase offline error
• 20. refund direct
• 21. refund moderated
• 22. reject direct offline
• 23. reject moderated offline

The buyer is a v5 node and the seller is a v4 node

• 24. cancel direct offline | blah |
• 25. complete direct online
• 26 complete disputed
• 27. complete moderated online
• 28. complete moderated with timeout
• 29. dispute close buyer
• 30. dispute close split
• 31. dispute close vendor
• 32. escrow release after timeout
• 33. fulfill direct online
• 34. market price modifier
• 35. out of inventory
• 36. purchase crypto listing
• 37. purchase digital
• 38. purchase direct offline
• 39. purchase direct online
• 40. purchase moderated offline
• 41. purchase moderated online
• 42. purchase offline error
• 43. refund direct
• 44. refund moderated
• 45. reject direct offline
• 46. reject moderated offline

---

Bonus points

We should really start validating the data structure of the API responses from the server to what we're expecting.

As a simple example, for POST /ob/listing (i.e. creating a new listing), a typical response would be:

{
    "slug": "eth-physical-order-testing-w-options"
}

We should validate:

1. The response is JSON
2. There is only one key with a name of slug
3. The value of this key is a string

A complex example would be POST /wallet/spend:

{
    "amount": "27404",
    "confirmedBalance": "1944250",
    "currency": {
        "code": "TLTC",
        "currencyType": "crypto",
        "divisibility": 8,
        "name": "Testnet Litecoin"
    },
    "memo": "Test spend testnet Litecoin",
    "orderId": "",
    "timestamp": "2019-10-11T03:02:40Z",
    "txid": "f9df310811c05bb8f21cae89cc5efc0c9bb18425ba16936267cd03fc09bb5822",
    "unconfirmedBalance": "0"
}

Here we should validate:

1. The each key names and currency object
2. The value types corresponding to each key (and nested object)