Give Love to JSONPath Implementation

[meerumschlungen]

I'd like to tackle the comment in https://github.com/TwiN/gatus/blob/master/jsonpath/jsonpath.go#L10
Eval is a half-baked json path implementation that needs some love

Rough Plan:

1. Max out test coverage for the current implementation
2. Properly re-implement the jsonpath package ensuring future extendability and maintainability, ensuring the tests from 1. pass for the new implementation
3. Max out test coverage for the new implementation
4. Run new tests from 3. against the old implementation to ensure backward compatibility
5. Check out benchmarks
6. Be happy (hopefully)

I do not intend to change or add functionality in the first place with the reimplementation but am eager to do so in the future since I could use it well myself.
This should provide a solid foundation for solving e.g. #335 or #225.

@TwiN Please confirm nobody's working on this already.
Thank you for your great work so far!

[TwiN]

Nobody's working on this right now! Though I'm a little curious about your intent. The needs some love part of Eval is a half-baked json path implementation that needs some love was more about implementing features that were missing from the current implementation, such as asterisks

[meerumschlungen]

I suggest rewriting the codebase, improving path parsing with a robust parser and tokenizer, improving type handling for consistent formatting of all JSON types, structuring the code for reusable parsed paths, and strengthening error handling with detailed messages. I find it difficult to achieve these improvements with the current codebase, especially regarding future extensibility with the missing features you mention. In addition, I'd like to add more tests and try to optimize performance, for example by reducing string operations.
I have already put some work into this and it looks quite promising so far. When I'm done, I'll submit a pull request.

[ImTheCurse]

I suggest rewriting the codebase, improving path parsing with a robust parser and tokenizer, improving type handling for consistent formatting of all JSON types, structuring the code for reusable parsed paths, and strengthening error handling with detailed messages. I find it difficult to achieve these improvements with the current codebase, especially regarding future extensibility with the missing features you mention. In addition, I'd like to add more tests and try to optimize performance, for example by reducing string operations. I have already put some work into this and it looks quite promising so far. When I'm done, I'll submit a pull request.

Couldn't agree more, the JSONPath is a bit of a nightmare to maintain.
@meerumschlungen let me know when you finish the rewrite I might take a look if I can find the time.

[meerumschlungen]

Thanks @ImTheCurse! It's still WIP but the core implementation is done in #1024 and the core implementation passes all unit tests. You can already review the code structure, if you like. It needs some tweaks to pass the integration tests especially when no valid JSON is present.
I'd suggest to move conversations about implementation details to the PR.

[r3mi]

Seing this issue, I am reminded that I have several endpoints where I need to do some JSON transformations from the API I want to monitor. For example, to count items in a JSON, or do some filters. To do that currently, I have intermediate simple services just doing a bit of curl + jq, between gatus and the real monitored service.
So having in gatus more advanced capabilities to transform JSON would be nice.