RPC callback block field is a string and not an object

[NiFNi]

Description of bug:

The RPC callback does send the block field as a string. So for example:

"block": "{\n    \"type\": \"receive\",\n    \"previous\": \"180EFCCCF87025CCC3C4DCB5FA4769004C702DB720B18537262AEC48C74D4189\",\n    \"source\": \"723DA447BD9BDA1892B4090544990722328F5000537956DFD7475A679FFD8249\",\n    \"work\": \"d56656b3f2f2fb6d\",\n    \"signature\": \"15DE8F4A01D6AAA2997BBCD3B14783EAA8CFF636A9B4EA8A7F3F6A8D79755746C301FC0590567FA62A18AADBBFAD04E466018445BF20A4CBA93204CC1E471B0E\"\n}\n"

In the wiki it is shown as JSON-object. So the same example should be like this:

"block": {"type": "receive", "previous": "180EFCCCF87025CCC3C4DCB5FA4769004C702DB720B18537262AEC48C74D4189", "source": "723DA447BD9BDA1892B4090544990722328F5000537956DFD7475A679FFD8249", "work": "d56656b3f2f2fb6d", "signature": "15DE8F4A01D6AAA2997BBCD3B14783EAA8CFF636A9B4EA8A7F3F6A8D79755746C301FC0590567FA62A18AADBBFAD04E466018445BF20A4CBA93204CC1E471B0E"}"

I like approach using JSON-objects seems more like what one would expect in my opinion. Is there a specific reason for it being a string? If not what about changing it to return an object by default while still being able to use the "legacy" mode for backwards compatibility by setting something in the config?

[NiFNi]

Same applies for retrieving a block over the RPC. This results in bad code on the listener side when using automatic JSON to object mapping. Simple Kotlin example with json_response being the body of the result of the rpc call and jacksonObjectMapper some json mapping library:

data class NanoBlock(val type: String, val previous: String, val destination: String,
                     val balance: String, val work: String, val signature: String)

data class NanoBlockStringWrapper(val contents: String)

val wrapped: NanoBlockStringWrapper = jacksonObjectMapper().readValue(json_response)
val validated: NanoBlock = jacksonObjectMapper().readValue(wrapped.contents)

[fu5ha]

I believe it's a string because that's the format that the RPC process command (and other ones that expect a fully rendered block as input) expects.

Edit: Which, in turn, I believe is because boost json parsing is buggy/questionable or something like that. Don't know all the details.

[pocesar]

it's actually a problem with the Boost library that doesn't (or is an expensive / unsafe operation) to do nested object serialization. so it just outputs the JSON string as-is (there was a discussion about this, but I couldn't find)

EDIT: #617 and #499

[clemahieu]

Yea we need to swap out the Jason serialization library or if someone wants to contribute that.

[rkeene]

I'm closing this ticket as a duplicate of #499 so that we can track the specific needed changes individually.