fix: Add results processor abstraction

[wtrocki]

Add the ability to inject different processors when processing offline results.
Different processors can be injected to review the data.

Currently, we have:

• id processor that will be injected from the cache layer and bound to helpers we provide. However, if someone is not using our helpers they may decide to not use those.

• conflict processor (optional with no conflicts involved)

[wtrocki]

More explanation from our side. When using custom optimistic responses in the framework (and from current usage I see that people will do that) our offline id remapping functionality is not working as optimistic response needs some special properties that will be missing.

Talked with the community member about it in the chat and instead of documenting and asking people to add special flags to their code (which can be lots of work depending on the size of app) it is better to provide custom processor and allow developers to provide their way of doing updates.

Without that application behaves improperly:

• Edits are created as new objects
• Every second operation on the object ends with conflict.

[darahayes]

@wtrocki thanks for that explanation that really helped me understand. So basically the OfflineQueue had some internal logic for

• Remapping server ids to client generated temporary IDs
• Bringing existing entries in the queue to the latest state returned in order avoid having mutations with incorrect state (version number) causing conflicts with ourselves (not 100% sure on this one)

But the main idea here is to define interfaces for those functions and allow people to override them with their own custom functions in case their applications handles things differently right?

[StephenCoady]

@wtrocki apologies, this one completely slipped through my queue somehow.

[wtrocki]

Yes. This operations modify existing offline queue after successful sync of single item. Abstraction will help to work with any type of data