Fix no-prototype-builtins bug in debug node and utils

[Alkarex]

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Proposed changes

Allows messages containing objects with no prototype built-in to be send to a debug node without crashing.

• In utils.js, constructs such as msg.msg.constructor.name will crash when msg.msg.constructor is null, for instance as a result of Object.create(null).

• In 21_debug.js, constructs such as msg.hasOwnProperty("status") might make the debug node crash/produce an error if the payload was created with Object.create(null).

This is the case e.g. for ini (to parse INI files), an official NPM node:
https://github.com/npm/ini/blob/4f289946b3bf95f144e849d771f64e4f2aa2737c/lib/ini.js#L63

My Node-RED node node-red-contrib-parser-ini, which is using that library, was hit by this bug and I had to ship a workaround
https://github.com/alexandrainst/node-red-contrib-parser-ini/blob/fe6b1eb4b18fd54459e2505b1c2f54eb0a9c9fec/parser-ini.js#L14 to make it work with the default output msg.payload of the debug node.

The msg.hasOwnProperty("xxx") construct should not be used since ECMAScript 5.1, and there is no guarantee that obj.constructor exists.

ESLint advises in the same direction https://eslint.org/docs/rules/no-prototype-builtins

This patch was produced using the following regex:
Search: \b([\w.]+).hasOwnProperty\(
Replace: hasOwnProperty.call($1,

This could be applied more globally if desired.

Checklist

• I have read the contribution guidelines
• For non-bugfix PRs, I have discussed this change on the forum/slack team.
• I have run grunt to verify the unit tests pass
• I have added suitable unit tests to cover the new/changed functionality

[Alkarex]

Such a fix might incidently be slightly helpful for bugs such as #2780

[Alkarex]

Another example: Same bug, but with overriding hasOwnProperty:

[
    {
        "id": "15a1b09eda5613f2",
        "type": "inject",
        "z": "d9a661f4.ef966",
        "name": "",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "{\"Hello\":\"World\",\"hasOwnProperty\":null}",
        "payloadType": "json",
        "x": 120,
        "y": 1200,
        "wires": [
            [
                "bdca2d4e9b10cdd7"
            ]
        ]
    },
    {
        "id": "bdca2d4e9b10cdd7",
        "type": "debug",
        "z": "d9a661f4.ef966",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": true,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "payload",
        "statusType": "auto",
        "x": 290,
        "y": 1200,
        "wires": []
    }
]

[coveralls]

Coverage decreased (-0.03%) to 67.306% when pulling 2e1e61d on Alkarex:fix-debug-node-hasOwnProperty into b7bae18 on node-red:master.

[knolleary]

Looks good. Thanks for the fix - with unit tests! All the better for it.

One small issue with the jsdoc - we don't want internal functions showing up in the generated doc for users.

[Alkarex]

I passed the tests locally with Node.js 12. I am not sure why the CI fails. Looks unrelated?

[knolleary]

Yup - unrelated test failure.

[Steve-Mcl]

Nick, for future reference, should we mark any internal APIs with @private - does the doc generator understand a jsdoc with @private is not for external use?

REF: https://jsdoc.app/tags-private.html

Private members are not shown in the generated output unless JSDoc is run with the -p/--private

That way re can decorate the functions with info to assist at development time?