feat: Implement JSON value matching

[piotr-roslaniec]

• Fixes feat: Implement JSON value matching for Manifest validation #491
• Introduces NotaryResponse and NotaryResponseBody to separate ManifestResponse and verification logic & parsing JSON
• Manifest.body.json now describes JSON path with an optional value matching
  • For n elements n>0, initial elements are treated as object keys and array indices, and element n+1 treated as a literal value
  • This offers a middle ground between adding another workaround for value matching/DSL, while being extendable enough to be retrofitted into a DSL without breaking changes
  • Note: This is a breaking change

[devloper]

@drewjenkins This PR fixes binance and Spotify, but requires breaking changes to the attest-integrations.

@piotr-roslaniec , can you help Andrew update the attest-integrations (link) to reflect your changes?

Also, we will need to update the docs for this new manifest description, @0xFloyd can you work with Piotr to update the docs?

[drewjenkins]

@piotr-roslaniec @devloper Does the rename from json->jsonPath have to happen for the fix? Asking because it won't only break attest-integrations, it will also break the SDK, and working version of the mobile app. It's fine if we want the change, just something to be aware of going forward that any breaking changes to the manifest could potentially break

• The chrome extension
• Docs/Manifest Builder
• Various version of the deployed iOS App (not in this scenario since the deployed version doesn't use response)
• Swift/Kotlin SDK
• React Native SDK
• Javascript/React SDK
• iFrame/Android App once released

[piotr-roslaniec]

@drewjenkins The renaming of the field is optional, but how it's interpreted will change, breaking some stuff: Previously we didn't expect the last element in the json to be a concrete value (optionally), but now we do. That being said, I haven't seen a single manifest that would be affected yet (as they usually specify keys only)

I updated the issue description.

This is the only breaking change I foresee before we roll-out a DSL, which will break everything.

[devloper]

Thanks for writing up the great list Andrew! We should almost make this into a check list for releasing these breaking changes quickly.

imo these breaking changes are perfectly fine and we should not be "afraid" to make them as long as we have good semantic versioning we should have control over when the changes goes out to all our SDKs and users can choose when they upgrade. We may need to improve our release management processes however to minimize the headache for ourselves.