Signed-off-by: Sujith mail.sujithvn@gmail.com

Resolves #6471
Impact: breaking
Type: feature

This PR replaces #6583

Issue

In the current system, the only way for order fulfillment is via shipping which is hardcoded into the system. We need to introduce the flexibility for users to add their own fulfillment types via plugins.

There is no way to verify if the order data in the UI is ready/complete and free of errors.

Solution

We are creating a base fulfillment plugin which would enable other fulfillment types (like shipping, pickup, digital) to be introduced via plugins. Each of the newly introduced fulfillment type plugin would need to have the specific fulfillment methods also to be added as separate plugins. Example, fulfillment type 'pickup' could have fulfillment methods like 'store pickup' and 'curb-side pickup'.

Along with the changes, we are creating a new API query end-point validateOrder which provides the option for frontend to validate the correctness and completeness of the order before actually placing the order.

Also, we are refactoring the placeOrder mutation and cutting down the functional layers

This PR is 5th entry (new-placeOrder refactor validateOrder)

PR Details in order

feat/fulfillment-types
 | 
 | __ 00 fulfillment base #6610 
 |        | __ new-fulfillment-type-shipping      #6614
 |        | __ new-fulfillment-type-pickup.    #6613 
 |__ new-fulfillment-impacted-plugins. [carts, products, orders, catalogs] #6615 
 |__ new-placeOrder refactor validateOrder  <--- This PR. #6616

Existing PRs based on the #6480 (to be updated to point to #6610)

We shall change the base branch of the 3 existing PRs (i18n #6545, dataMigration #6544, setDefaultFFtype #6543) to point to 00 fulfillment base

Details (specific to placeOrder refactor and introduction of validateOrder end-point)

• Moved out most of the functionalities from placeOrder to prepareOrder.
• Flattened out the hierarchical function calls by 1-2 levels and placed all the called functions in folder orderValidators inside util. Most of the functions are copied over from existing code base.
• prepareOrder builds up the order object and performs the validation steps in parallel. Validation results are accumulated in an array for most of the errors except the initial 2-3 errors where we return with the error.
• Both placeOrder and validateOrder calls prepareOrder with respective flags.
• Few steps specifically are related to payments auth and are skipped in case validateOrder is calling prepareOrder.
• In case of validateOrder call, most of the function calls are placed in a try-catch block to collect the errors. In case of placeOrder call, functions are directly executed.
• Final order object is validated against the schema (in case of prepare order, it is validated against a custom schema).
• prepareOrder returns Order & token to placeOrder, and returns success flag and validationResults to validateOrder.
• placeOrder will finally insert the order returned by prepareOrder into the DB and completes the placing of order.

Breaking changes

Since this is the new way of handling fulfillment, the existing shipment plugins would not work along with this. User would need to migrate the data (migration script will be developed) and remove the shipment plugins (api-plugin-shipments and api-plugin-shipments-flat-rate).

Testing

All this is new code and at this stage this is not integrated to reaction, meaning the plugins.json is not updated to include this plugin. Hence proper testing can be carried out only after merging in the remaining PRs.