Woocommerce analytics for suborder

[Aunshon]

All Submissions:

• My code follow the WordPress' coding standards
• My code satisfies feature requirements
• My code is tested
• My code passes the PHPCS tests
• My code has proper inline documentation
• I've included related pull request(s) (optional)
• I've included developer documentation (optional)
• I've added proper labels to this pull request

Changes proposed in this Pull Request:

Fix the analytics order for refund orders and orders.

Closes

• Closes https://github.com/getdokan/dokan-pro/issues/3289

How to test the changes in this Pull Request:

• Remove all data from {prefix}_wc_order_stats table in database.
• Delete Previously Imported Data from Admin dashboard -> Analytics -> Settings You may see the button at the end of the page.
• Clear analytics cache from Admin dashboard -> Woocommerce -> Status -> Tools.
• Order from multiple vendors so that dokan can create suorders.
• Create Wcoocommerce subscription product buy and make order with it, and run the subscription payment scheduler woocommerce_scheduled_subscription_payment from Admin dashboard -> Woocommerce -> Status -> Scheduled Actions so the recurring order can be created intantly.
• Do all the above things and check the data before and after the PR.
• Also make sure to test this issue Fix/incorrect woocommerce analytics #2140

Changelog entry

**fix:** Missing refund orders for WooCommerce Analytics for dokan sub order

Detailed Description of the pull request. What was previous behaviour
and what will be changed in this PR.

Before Changes

Describe the issue before changes with screenshots(s).

After Changes

Describe the issue after changes with screenshot(s).

Feature Video (optional)

Link of detailed video if this PR is for a feature.

PR Self Review Checklist:

• Code is not following code style guidelines
• Bad naming: make sure you would understand your code if you read it a few months from now.
• KISS: Keep it simple, Sweetie (not stupid!).
• DRY: Don't Repeat Yourself.
• Code that is not readable: too many nested 'if's are a bad sign.
• Performance issues
• Complicated constructions that need refactoring or comments: code should almost always be self-explanatory.
• Grammar errors.

FOR PR REVIEWER ONLY:

As a reviewer, your feedback should be focused on the idea, not the person. Seek to understand, be respectful, and focus on constructive dialog.

As a contributor, your responsibility is to learn from suggestions and iterate your pull request should it be needed based on feedback. Seek to collaborate and produce the best possible contribution to the greater whole.

• Correct — Does the change do what it’s supposed to? ie: code 100% fulfilling the requirements?
• Secure — Would a nefarious party find some way to exploit this change? ie: everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities?
• Readable — Will your future self be able to understand this change months down the road?
• Elegant — Does the change fit aesthetically within the overall style and architecture?