Preparing for Immutable / Limited ArrayBuffer

[jasnell]

• https://github.com/tc39/proposal-immutable-arraybuffer
• https://github.com/tc39/proposal-limited-arraybuffer

The Immutable ArrayBuffer and Limited ArrayBuffer proposals are advancing in TC-39. We have some time before we need to worry about them but we do need to prepare.

An Immutable ArrayBuffer is exactly what it says on the tin. Once allocated and marked immutable, the memory is expected to remain stable and unmodified -- even at the host runtime level. This obviously means that our current ArrayBuffer <-> kj::Array<kj::byte> type mapping will need to be updated to account for the possible immutability of the underlying backing store.

To support this, I am proposing:

• We update jsg::BufferSource to add a new "isImmutable()" property, and when the jsg::BufferSource is wrapping an immutable backing store, the kj::ArrayPtr<T> it produces to provide access to the underlying data would be a kj::ArrayPtr<const kj::byte>. Modifications to the underlying data would be blocked.
• We add a new Immutable ArrayBuffer <-> const kj::Array<const kj::byte> type mapping and make it so that the current ArrayBuffer <-> kj::Array<kj::byte> type mapping receives an immutable ArrayBuffer an error is thrown.

The Limited ArrayBuffer proposal provides a way of generating a read-only View of an otherwise mutable ArrayBuffer. When given such a view, it MUST be treated equivalently as an Immutable ArrayBuffer even if the underlying backing store is mutable. We ought to be able to handle this transparently in the type mapping modifications mentioned above.

There is no rush on this, however, and the changes required are relatively straightforward so work on this should proceed only when v8 implements the feature and ships it unflagged.