In-memory order updater

[benjaminwil]

Summary

This pull request proposes a replacement to the default Spree::OrderUpdater that has new and improved functionality:

• Increased performance due to the updater making fewer write calls to the database.
• A built-in update simulator, so that changes to an order can be previewed before persisting them.

There may be some beneficial side-effects that come out of this new order updater implementation:

• Significantly faster order factories, and thus a significantly faster test suite for Solidus gems and Solidus applications.

We don't expect this to be the default order updater implementation in the next minor version of Solidus, but we would like to propose it as the default for the next major version of Solidus.

Note: The commits on this pull request have a long list of co-authors, as the Super Good team is approaching this as a collaborative mob programming exercise.

Milestones

For this order updater, we intend to achieve the following during updates:

1. Don't perform writes to the database.
2. Preload associated records to eliminate reads required.

We appreciate that there is a lot of complexity to achieving these goals (dealing with active promotions, for example).

Notes

• We should provide more context about performance gains in this PR description. It would be insightful to include the actual number of writes the current Spree::OrderUpdater makes on a typical recalculate.
• We should further explain why a production store may want to use an order update simulator so it's clear why this feature is worth having. For now, I'll just say that we have worked with stores who could benefit from this feature. Sometimes admins must make significant changes to completed orders, and it would be valuable for them to preview a set of changes before submitting them and causing updates on many order-associated tables.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[jarednorman]

Just making a note that we are waiting on Alistair to rebase #6026 against this.

@AlistairNorman could you just make sure that gets done at some point before the 20th? That way we can have it for our next session.