Add parseJsonKeys() cheatcode

[klkvr]

Motivation

Currently there is no way (or at least I didn't find one) to get keys of a JSON object

Solution

Create new cheatcode parseJsonKeys(string calldata json, string calldata key)

Examples:

parseJsonKeys('{"key1": "value1", "key2": "value2"}', '$') // returns ["key1", "key2"]
parseJsonKeys('{"key1": {"inner_key1": "inner_value1", "inner_key2": "inner_value2"}, "value1", "key2": "value2"}', '$.key1') // returns ["inner_key1", "inner_key2"]

[klkvr]

Actually, this could have been possible just with usage of something like parseJson(jsonString, ".*~"), but jsonpath lib for Rust does not support such operators (freestrings/jsonpath#69)

[mds1]

should we add a parseJsonKeys(string)(string[]) to parse the root keys? might be better UX than passing $ as the key, but I don't do tons of jsonpath stuff so maybe $ is common/standardized and we should stick with just that?

[Evalir]

hey! sorry for the delay on this, looks great. just a nit! also need to resolve conflicts

[Evalir]

Let's use ? instead of unwrapping here so we don't panic

[klkvr]

hey @Evalir I have pushed resolved conflicts

regarding unwrap(), there is an is_object() check above which guarantees, that if it returns True, than as_object will not return None. Considering this, should I add ? anyways?

[Evalir]

hey hey @klkvr coming back to this—yes ideally! even if it's a guarantee it's best to not introduce any panicking. feel free to use wrap_err to add a message to it indicating that it should not fail

[Evalir]

lgtm as soon as we remove the unwraps!

[klkvr]

hey @Evalir rebased from master and removed unwrap

[Evalir]

Thank you! Let's add docs for this on the book & forge-std pr @klkvr