refactor: cookieParser.ts to be safer and simpler

[acetousk]

Description

I found a more simple and less null ptr exceptions way to write cookieParser.ts's cookieParser method in 2 lines. It turns out that there was no null handling when checking for whether the data was actually returned from a different system.

Related Issue

Motivation and Context

This is better code for Prestashop and more flexible for Moqui.

How Has This Been Tested?

Running yarn dev, and going through the process of submitting an order, getting information and looking at the logs.

Looks like there aren't any tests already after running yarn test.

Screenshots (if appropriate):

Types of changes

• [x ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x ] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [x ] All new and existing tests passed.

[samberrry]

@acetousk thanks for your contribution, your NPE check is okay, however there is a prestashop-specific consideration about cookies that should be taken into account. first let me explain how prestashop works with cookies. Actually prestashop generates many cookies in different situations. First when we call any of the APIs it generates a cookie for that session - to keep track of that guest user. Once the guest user tries to register prestashop generates another cookie, to keep track of the logged in user (now customer). Add to cart and other endpoints should be called with that second cookie. So, we should always use the last generated cookie for the future API calls. That's why I looped over the cookie array and got the last element (we know that all prestashop cookies have PrestaShop word).