Process (de)serialization collides with `sealed` keyword

[edan-bainglass]

Steps to reproduce:

1. Load a WorkChainNode (you can submit and load a MultiplyAddWorkChain if you don't have another)
2. Serialize it with serialized = node.serialize(), assuming node is the loaded WorkChainNode
3. Recreate the WorkChainNode with WorkChainNode.from_serialized(**s)

I get TypeError: SqlaNode.__init__() got an unexpected keyword argument 'sealed'.

Not sure at the moment if this was considered and accepted as is, but naively I would think processes should be compatible with a serialization roundtrip.

[edan-bainglass]

Note that one cannot simply pop the sealed keyword from the serialized input, as it is required by Sealable.Model, which is mixed into ProcessNode.Model.

[edan-bainglass]

This matter can be handled by excluding certain fields from serialization (via exclude_to_orm) to the point that the serialized dict fits to the constructor's signature. However, this is probably not the path. It is likely that some if not all such excluded fields are important information pertaining to the serialized node, and thus exclusion would defeat the purpose.

An alternative is to adjust the constructor (backwards-compatible-ly) such that it can accept these arguments. There is some discussion on this matter here.

Will think of this some more.

[edan-bainglass]

@agoscinski to summarize, there exists a mismatch between model fields and constructor parameters for some ORM entities. In some cases, the lack of a constructor override (or lack of partial explicit argument handling, leaving others to kwargs) means that some or all fields designated for deserialization may end up at the backend's SqlaNode constructor, which is strict (no kwargs), in which case, error!

I try to handle this in #6990, but I'm not an expert on the full ORM, so it is not always clear which fields should or shouldn't arrive at a constructor (@sphuber introduced exclude_to_orm to control this on the model).

I make a note here on a potential guide to this, following the REST API implementation. However, considering that the REST API is up for an update, and that the current implementation if one of @chrisjsewell, it may raise further questions. Good to discuss.

[edan-bainglass]

This is perhaps not an issue if one considers that processes are not to be created as a Node directly, but only posted via submission of a process, which would use a dedicated model, not ProcessNode.Model. Closing for now.