refactor: allow ES import for cloud string if package type is module

[dblythy]

New Pull Request Checklist

• I am not disclosing a vulnerability.
• I am creating this PR in reference to an issue.

Issue Description

Currently, if package type is module, specifying a cloud string does not work.

Related issue: #7559

Approach

Checks env variable npm_package_type, which is autoset, and if it's a module, uses import() instead of require()

TODOs before merging

• Add test cases
• Add entry to changelog

[parse-github-assistant]

Thanks for opening this pull request!

• 🎉 We are excited about your hands-on contribution!

[codecov]

Codecov Report

Merging #7560 (7af6c16) into master (fdb7dfb) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #7560   +/-   ##
=======================================
  Coverage   93.94%   93.95%           
=======================================
  Files         181      181           
  Lines       13279    13281    +2     
=======================================
+ Hits        12475    12478    +3     
+ Misses        804      803    -1     

Impacted Files	Coverage Δ
src/ParseServer.js	90.00% <100.00%> (+0.11%)	⬆️
src/ParseServerRESTController.js	98.50% <0.00%> (+1.49%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fdb7dfb...7af6c16. Read the comment docs.

[mtrezza]

Could you resolve this conflict? Sorry, this will go away with release automation, hopefully by this month.

[mtrezza]

Looks good!

[parseplatformorg]

🎉 This change has been released in version 5.0.0-beta.1

[Moumouls]

So as discussed with @mtrezza , here @dblythy we have an issue, import is async. This is a race issue. A developer do not have any guarantee that the code will be loaded before he try to run some cloud code functions. We have some recurrent CI fails due to this feature (https://github.com/parse-community/parse-server/actions/runs/1426220570)

Last months and also with #7525 we have evidence that the Parse server start up should be refactored with a clean async start function. Then we can drop the old constructor pattern (not flexible at all since we cannot return a promise)

For now the PR could introduce huge problem in a prod environment. i'll recommend to revert this PR.

I'll open an additional Issue with a first suggestion of the spec for the Parse Server start async fn. And also a suggestion of feature implementation to avoid a breaking change with a support of both constructor system and async fn during one major version.

[parseplatformorg]

🎉 This change has been released in version 5.0.0