Improve manifest `extra` field processing

[roman-khimov]

Summary or problem description While #2254 solved the main part of #2181 there is still one field in manifest that is parsed and serialized as JSON --- extra. As per NEP-15 (neo-project/proposals#114) it's an opaque JSON object that can contain anything inside, so basically it has the same problem we had with whole manifest before. At the same time it's a bit different in that we don't actually care about this field's contents, we just store it.

Do you have any solution you want to propose? Several options:

• remove extra completely (is it useful?)
• change it to string (it should be enough)
• store extra as is, that is do not parse this field into JObject at all and store a string of original data ({"a":"b"}, not sure current parser allows for that, but technically that's quite easy)

Neo Version

• Neo 3

Where in the software does this update applies to?

• ContractManagement contract
• Manifests (NEP-15)

[erikzhang]

remove extra completely (is it useful?)

It can be used to store the developer's info.

[superboyiii]

remove extra completely (is it useful?)

It can be used to store the developer's info.

Maybe String is enough, I think we can change.

[superboyiii]

@roman-khimov How do you implement JsonSerialize() and JsonDeserialize() in Json API of neo-go's contract？ I think they will also meet this issue. extra is not the only case?

[roman-khimov]

JSON serialization/deserialization uses different code that converts things into/from stack items and that code is compatible I think. But manifests are converted into appropriate structures and this code uses standard Go JSON parser. We do not parse this field at all at the moment which helps (its value is retrieved and stored as raw string), but still it shouldn't be hard to create some JSON input that will be binary different from the original after deserialization/serialization and that will break compatibility for us. Using simple string should be sufficient.