feat: Model merging with delta objects

[byronxu99]

• Add a new VW::model_delta object that internally keeps a VW::workspace
• Define operators + and - such that deltas are created by subtracting two workspaces, and can be added to update a workspace
• Add a merge_delta function that combines multiple deltas into a single delta
• Refactor model merging to be implemented via delta merging

[olgavrou]

It looks like model_delta is just a wrapper around a workspace that is used to communicate that this holds a delta

Wondering if the +/- operators should be operators of the workspace class leading to a more intuitive API for those operators, and it would also mean that we avoid wrapping workspaces into deltas in order to merge them

If we need to indicate that a workspace is a diff we could add a bool field indicating that it is a diff, or maybe model_delta could be derived from workpace

Thoughts?

[byronxu99]

Yes, as it is right now model_delta simply is a wrapper around VW::workspace that makes types explicit and specifies ownership. I think this provides a greater level of safety than the alternative of having an is_delta flag inside of workspace.

The - operator already operates on the workspace class, but returns a model_delta. The + operator I've defined as an "update a workspace with new changes" operation, and thus requires a workspace and a model_delta.

I specifically do not want + to be a "merge" operation, that is, to work on two workspaces or two deltas. The reason is that it won't work for merging GD with save_resume, which must have access to the set of all workspaces being merged at once, instead of just two of them at a time. Otherwise, we could have implemented the merge function in terms of +, -, and a "multiply by scale factor" operation, which I would find more intuitive.

The case of "wrapping workspaces into deltas in order to merge them" isn't as bad as it seems as first. In federated learning, we would be directly receiving deltas to pass to the merge function - having to merge workspaces via deltas would be the less common use case. It also simplifies the merge logic inside of each and every reduction, because now there's no longer a requirement to check for a base workspace and subtract it if it exists.