src: add proper MemoryInfoName to wrappers

[joyeecheung]

• Use camel case names for memory retainers inherited from AsyncWrap
  instead of their provider names (which are all in upper case)
• Assign class names to wraps so that they appear in the heap snapshot
  as nodes with class names as node names. Previously some nodes are
  named with reference names, which are supposed to be edge names
  instead.

Before (in DevTools):

After:

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[nodejs-github-bot]

@joyeecheung build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/338/pipeline

[joyeecheung]

cc @addaleax

[addaleax]

Hm... I think I'd prefer it if we could stick to one naming scheme for diagnostic information we provide for AsyncWraps. I do prefer CamelCase like you introduce it here, and I think we should have also been providing CamelCase in async_hooks from the very beginning. I'm not sure we can still make that switch? /cc @nodejs/async_hooks

[joyeecheung]

@addaleax We have more wraps than just the async wraps though, if we want to stick to the naming scheme we will end up polluting all the names including those that do not have async resource provider equivalents and types of different levels, e.g. QueryNaptrWrap v.s. QUERYWRAP.

Also for tooling, it's easy to convert camel cases to upper cases, but not the way around.

For the async hooks the ship may have already sailed since we have documented those types for quite some time? For heap snapshots the names are mainly used for aggregation, the users may still end up going back to the source so I don't think there is a need to document them down.

[devsnek]

just out of curiosity, do any of these not match the class name? maybe you could set it up with like typeid(this).name() or something

[joyeecheung]

@devsnek Some of them do, e.g. TCPWrap is divided into TCPSocketWrap and TCPServerWrap mainly because they are also differentiated as async resources. We could probably make this the default behavior of BaseObject, although RTTI (in non-tests) is advised against in Google's style guide and V8 always avoid using that by explicitly using macros (which is also done in this PR)

[addaleax]

Okay, makes sense -- I still think it would be great to eventually have consistency between this and async_hooks. It's not just casing that's different currently, though (e.g. ZLIB vs ZCtx)...

[joyeecheung]

CI: https://ci.nodejs.org/job/node-test-pull-request/15988/

[joyeecheung]

Another CI: https://ci.nodejs.org/job/node-test-pull-request/15994/

[joyeecheung]

Landed in 28a3e28, thanks!