Make JSON deserializer more robust

[lbajolet]

When working on missions, I noticed that the JSON deserializer was a bit too fragile and caused the server to crash multiple times.
When attempting to deserialize malformatted data from client, the deserializer crashes due to some asserts left in the library.

I'd propose to return nullable when deserializing, such that when a bad packet is received, the client needs to handle the possibility of a null instead of letting the whole application crash on an assert fail.
This does change the API-side a bit though.

@xymus since you are the main developer/maintainer of the library, do you have any idea to make the whole serialization/deserialization more robust while avoiding to burden the clients too much ?

[xymus]

What method are you thinking about? Deserializer::deserialize already returns a nullable Object.

There should not be any abort or casts left in the json::serialization module. Please send me the stacktrace if you have such an error.

As usual, don't forget to check for errors:

• After calling Deserializer::deserialize, always check Deserializer::errors. If a single error was raised you should not trust the returned value. (This isn't true per say, some errors can be ignored, but if you want an easy deserialization, consider that any error report the data as corrupted.)
• If you don't care for partial objects you can set Deserializer::keep_going = false, it will stop deserializing an object on the first error. But still, the even more empty objet will be returned and you must check for errors. This may make debugging easier, but usually it is more relevant for the binary deserialization.

[xymus]

By the way, deserialize returns null on 2 conditions:

• The deserialized data is a null.
• There was a fatal error (the JSON object was invalid or something like that).

[xymus]

Edited my previous comments after I read the doc of keep_going.

[privat]

I had a crash recently:

import json::serialization

class A
    serialize
    var field: Int
end

var des = new JsonDeserializer("garbage")
var a = new A.from_deserializer(des)
print des.errors
print a.field

../lib/json/serialization.nit:293,3--26: Runtime error: Assert failed
            assert not path.is_empty # This is an internal error, abort
            ^
,---- Stack trace -- - -  -
| serialization$JsonDeserializer$deserialize_attribute (../lib/json/serialization.nit:293,3--26)
| x$A$from_deserializer (7,14--52)
| x$Sys$main (x.nit:9,9--36)
| kernel$Sys$run (../lib/core/kernel.nit:296,13--16)
`------------------- - -  -

[xymus]

@privat Haa, that was why we didn't use from_deserializer directly... I'll fix it, but you should still not use it when you can avoid it.

[lbajolet]

What @privat reported is exactly the problem I had, admittedly the instanciation method might not be the most appropriate when dealing with unsafe sources.
I'll see what I can do to avoid using it directly in client code.

[xymus]

Was it a single bug? is it fixed by #2295?