Remove the use of sdb_json_* API

[XVilka]

Remove use of sdb_json_* API:

[i] ℤ rg sdb_json                                                                                                                                                                                                                 17:37:22 
librz/cons/grep.c
501:                    char *u = sdb_json_get_str(cons->context->buffer, grep->json_path);

librz/debug/dsession.c
399: * - This mostly follows rz-db-style serialization and uses sdb_json as the parser.

For parsing JSON there is already librz/util/json_parser.c/librz/include/rz_util/rz_json.h API. Good example on how to use such an API is in librz/analysis/serialize_analysis.c.
For storing configuration it's better to use something different.

[ret2libc]

What's the status of this? Is anything missing?

[XVilka]

@ret2libc the panels PR is already there, it's just blocked by the unrelated bug in loading layout - it wasn't working even before my change.
The missing part is the use of sdb_json in librz/cons/grep.c - I had no time to fix it.

[ret2libc]

@XVilka Postponing this to one of the next releases then?

[XVilka]

It is quick to do once more important issues are finished. Wait until 0.3.0 is closer, then we can consider to move this if not possible to finish.

[XVilka]

The librz/cons/grep.c conversion is tricky, since it supports long JSON paths, e.g: ~{[0].methods[2].flags[0]}, while librz/util/json_parser.c doesn't - it's json_get() function handles only one level without recursion. Thus, to fully solve this issue the JSON parser should be extended.

[XVilka]

Blocked by #1108

[ret2libc]

Blocked by #1108

So according to this, this issue should not be blocked anymore, right?

[XVilka]

@ret2libc it will be closed once #1118 is finished and merged. Apparently, new JSON Path doesn't work in all cases that were covered by sdbjson, see failed tests at https://builds.sr.ht/~xvilka/job/534185#task-test-0

Some cases are tricky, for example aflj~{main}:

[XX] db/cmd/cmd_afl aflj
RZ_NOPLUGINS=1 rizin -escr.utf8=0 -escr.color=0 -escr.interactive=0 -N -Qc 'aaa
aflj~{main}
' bins/elf/ls
-- stdout
--- expected
+++ actual
@@ -1,1 +1,1 @@
-{"offset":23264,"name":"entry0","size":46,"is-pure":"false","realsz":46,"noreturn":false,"stackframe":8,"calltype":"amd64","cost":15,"cc":1,"bits":64,"type":"fcn","nbbs":1,"edges":0,"ebbs":1,"signature":"entry0 (func rtld_fini);","minbound":23264,"maxbound":23310,"callrefs":[{"from":23304,"to":138776,"type":"CALL"}],"datarefs":[68710,92000,68591,91888,16496,115466],"indegree":0,"outdegree":1,"nlocals":0,"nargs":1,"bpvars":[],"spvars":[],"regvars":[{"name":"rtld_fini","kind":"reg","type":"func","ref":"rdx"}],"difftype":"new"}
+[{"offset

aflj returns a JSON array, so JSON path .main would be invalid. What old code did, it was searching all elements that has main string somewhere and printing that. Not sure how to solve this conundrum.

[ret2libc]

@ret2libc it will be closed once #1118 is finished and merged. Apparently, new JSON Path doesn't work in all cases that were covered by sdbjson, see failed tests at https://builds.sr.ht/~xvilka/job/534185#task-test-0

Some cases are tricky, for example aflj~{main}:

[XX] db/cmd/cmd_afl aflj
RZ_NOPLUGINS=1 rizin -escr.utf8=0 -escr.color=0 -escr.interactive=0 -N -Qc 'aaa
aflj~{main}
' bins/elf/ls
-- stdout
--- expected
+++ actual
@@ -1,1 +1,1 @@
-{"offset":23264,"name":"entry0","size":46,"is-pure":"false","realsz":46,"noreturn":false,"stackframe":8,"calltype":"amd64","cost":15,"cc":1,"bits":64,"type":"fcn","nbbs":1,"edges":0,"ebbs":1,"signature":"entry0 (func rtld_fini);","minbound":23264,"maxbound":23310,"callrefs":[{"from":23304,"to":138776,"type":"CALL"}],"datarefs":[68710,92000,68591,91888,16496,115466],"indegree":0,"outdegree":1,"nlocals":0,"nargs":1,"bpvars":[],"spvars":[],"regvars":[{"name":"rtld_fini","kind":"reg","type":"func","ref":"rdx"}],"difftype":"new"}
+[{"offset

aflj returns a JSON array, so JSON path .main would be invalid. What old code did, it was searching all elements that has main string somewhere and printing that. Not sure how to solve this conundrum.

I think the test is just wrong... there is no main defined anywhere in the expected output. I'd say to add a bunch of tests in your PR and be rigid about the filter applied between {...}.