Add draft support for adding/removing/modifying other data elements in dataProcessWrite

[ivarne]

The main goal is to add a method to IDataProcessor that takes an IInstanceDataAccessor and a list of changes and to add methods to IInstanceDataAccessor to add and remove data elements.

Major refactorings

• New service ModelSerializationService to handle (de)serialisation of json and xml with convenience methods *Storage that looks in applicationmetadata
• Extend IInstanceDataAccessor with methods to add and remove data elements from the instance
  • These are currently lazy, which means that they return void, and updating storage is deferred till after data processing is complete
• Extend CachedInstanceDataAccessor with functionality to ensure that nothing has been changed, after a certain point. This is used so that after data processing we can save to storage in parallel with validation without having to worry about validators mutating the models undetected.
• DataElementId was previously intended to be a thin wrapper around System.Guid, to communicate that this isn't just any guid, but a Guid from a specific database column. Every time I created one it was from a DataElement, and it was often required to get the data type, so I added fields to avoid lookups. Now it is more of an Immutable DataElement. Not sure everybody loves that development.
• DataClient uses the new ModelSerializationService and IDataClient gets a new GetDataBytes to argument the old GetBinaryData for those who want a clean byte[] that isn't wrapped in a Stream.

Open questions

• New IDataProcessing interface, or just extend the existing with a new method. What to call the new one in that case?
• I got some help from ChatGPT to write MemoryAsStream in order to be able to pass ReadOnlyMemory<byte> to functions that expects a stream. I also found an alternative in Windows Developer Toolkit. I'm not sure it is worth including a full toolkit for 14 effective lines of code.

Remaining updates to make old code conform to new patterns

• Deprecate ModelDeserializer and use ModelSerializationService everywhere.
• Use IInstanceDataAccessor instead of IDataClient in more places where it makes sense to use the new data-processing interface
  • Instance creation
  • Data POST
  • Data PUT
  • Simpler detection for action implementations
  • Run new data-processing method on file/attachment upload

Related Issue(s)

• New IDataProcessing interface that supports multiple DataElements and adding elements in response to changes #776

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[martinothamar]

IInstanceDataAccessor feels a lot more important now then the name suggest, maybe we should consider a new name before we merge to main?

[ivarne]

IInstanceDataAccessor feels a lot more important now then the name suggest, maybe we should consider a new name before we merge to main?

Do you have any suggestions?

edit: We decided to split the interface into IInstanceDataAccessor and IInstanceDataMutator which inherits from the former

[ivarne]

Merging this now, so that we get back to having only one PR