Add helpers to deserialise JSON-LD in a more robust way

[tesaguri]

This patch implements some helper functions to translate JSON-LD data structures to something easier to deserialise as Rust data structures, and applies them to the types in kitsune_type::ap using the #[serde(deserialize_with = "…")] attribute.

This also replaces some usage of the #[serde(untagged)] helper types (which basically works by deserialising the full input to a DOM and tries to deserialise it to the variants one by one until succeeds) with the new helpers.

Admittedly, the hand-written DeserializeSeed implementations are full of boilerplates (as they generally tend to; Serde's builtin implementations are similarly verbose, for instance), with ~5x more lines of code than Mitra's deserialization.rs. Yet I think they're reasonably modular and maybe efficient (no benchmarks though!).

In case you're not familiar with it, think of an impl DeserializeSeed value as a closure-version of the generic Deserialize::deserialize function. Using the trait allows composing the deserialize functions in a higher order function-like manner. The patch takes advantage of it to compose the FirstId helper from the Id and First helpers, and the IdSet helper from the Id and Set helpers.

Closes #489.

[aumetra]

Thanks for the thorough PR! Will have a look at it

[aumetra]

This is just a small surface level overview I had. I have to read a bit more into serde to give a final review.

I know about some of the concepts (like DeserializeSeed, which is essentially just deserialization that allows to pass state) but I gotta refresh on them..

[tesaguri]

DeserializeSeed, which is essentially just deserialization that allows to pass state

Yeah the docs explain that much, but the seeds in the patch don't really have any runtime state. Rather, the helpers in the patch view the seed as a sort of callback, which might be a twist to the docs' view.

[tesaguri]

As a next step, we may want to make the model types accept unknown extension types in attachment, tag, etc. For example, Kitsune currently gives up deserialising a whole Object when it encounters a FEP-e232 object link (a "type": "Link" value in tag).

But that looks like an Activity Streams-specific logic rather than the general JSON-LD logic which the patch aims to focus on, and that would also involve less trivial design decisions¹, so I think it's better to leave it off in the patch.

Footnotes

1. e.g. Should we store unknown attachment/tag verbatim so that we can inform users something like "the post contains unknown attachment/microsyntax", or should we just skip unknown elements? And if latter, I have no idea of an efficient way (i.e. without deserialising the elements to an intermediate DOM) to achieve it (though a few compromises might be just okay as a starter). ↩

[aumetra]

Yeah, as a next step for immediate fixing of these issues, we should just type out an alternative field in those enums declared with #[serde(other)] to not reject valid ActivityStreams objects

[aumetra]

Not a review, just noting: Wow, this is really just an undocumented functionality, huh?

[aumetra]

I think I grasped enough of the code to give this an okay