src: migrate to newer V8 ArrayBuffer APIs

[addaleax]

src: migrate off ArrayBuffer::GetContents

V8 deprecates GetContents() in favour of GetBackingStore().
Update our code to reflect that.
V8 also deprecates Externalize() and IsExternal(); we should
be able to remove all usage of this once V8 8.0 is there.

Refs: v8/v8@bfe3d6b

src: drop CallbackInfo for Buffer lifetime tracking

This has been rendered unnecessary by upstream V8 changes,
which now allow user-provided deleter functions out of the box.

(Sadly, that function signature mismatches our deleter function
signature, so we still need a heap allocation to track our deleter
data.)

Refs: v8/v8@bba5f1f

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

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

[devsnek]

🎉

[cjihrig]

LGTM, and thanks for the heads up in the WASI PR.

[addaleax]

I’ve dropped the second commit (be7e6e6ecf829fa859dab7a37f3732f021fb1b57) for now, and restored the IsExternal() condition in node_messaging.cc.

The reason for the CI failures was that V8’s BackingStoreDeleterCallback was invoked directly by GC, and not in the GC epilogue like weak callbacks. This meant that the callback could be invoked by any thread, and we’d have to emulate the previous behaviour of running it on the main thread somehow.

Two possible solutions that I’ve discarded for now:

1. Use the platform’s GetForegroundTaskRunner() and schedule a foreground task ourselves. This doesn’t work well because it won’t work for embedders that don’t provide a platform implementation to Node.js (only to V8).
2. Use an uv_async_t on Environment or similar. This doesn’t work well because ArrayBuffers can outlive Environments (and even Isolates).

Ultimately, I think the best solution is sadly an API migration/change to something closer to what V8 does. The fact that ArrayBuffers can be transferred between Isolates means that, in an ideal situation, the free callback should not rely what on what thread it is invoked on; we currently only work around this by copying external ArrayBuffers rather than transferring them.

That this design flaw has made it’s way into N-API is unfortunate. Maybe we can eventually tag ArrayBuffers created through these APIs (the current Buffer::New() with a callback and napi_create_external_{array,}buffer) as non-transferable in some way, and handle all other ArrayBuffers properly.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[danbev]

Landed in e66a2ac.

[MylesBorins]

If we backport 7.9 to 13.x we might want to include this. Thoughts @addaleax?