[Marketplace] Rethink implementation of order shipping fulfillment flow

[kieha]

Referenced from #2613, there is need to rethink the implementation of the order shipping fulfillment flow to make it more flexible and extensible.

We should also rethink the hard coded zeroth indexes of the billing and shipping arrays in the order object. This should be more flexible to allow for multiple billing and shipping objects that might be there in the marketplace implementation.

[spencern]

Additionally we need to think about the flexibility of how we're progressing and regressing workflow steps.

From a comment I made on #2613

I'm always open to new ways to do things, but it seems like we should have "orders/progressStatus" and "orders/regressStatus" methods instead of one method per status.
We could then have a set of workflows that identifies the next or previous status from the existing status and proceeds. There could be different states for items than for orders, and each should be overridable.
This seems like it would make it easier to extend or replace functionality because if you replace the workflow set, then you replace the way that orders progress.

[aaronjudd]

@kieha what's the estimated timeline on this? is it in progress? I consider this to be a (asap) critical issue. Can you please schedule a time to review the approach with @spencern or myself on this before beginning.

[kieha]

@aaronjudd this is not yet in progress. I'll reach out to you and/or @spencern ASAP before I start on it.

[kieha]

A bit more discussion/comments on what should be done here to be found in this PR #2759.

In summary:

• In addition to rewriting the backend methods, a lot of rewrites need to happen in the front end code as well. I've added comments in the respective files, especially imports/plugins/core/orders/client/containers/orderDashboardContainer.js as to what would need to be done.

[aldeed]

Done in 2.0.0