[ECO-4737, ECO-4756] Fix auth token encoding in React Native

[VeskeR]

Resolves #1730 , resolves #1749

Fixes incorrect usage of the underlying ArrayBuffer buffer in web BufferUtils, where we didn't account for the byteOffset and byteLength of the original array buffer view. This resulted in us incorrectly encoding auth tokens in the React Native bundle, where we use a polyfill for the TextEncoder class, which returned Uint8Array as a subarray of the underlying ArrayBuffer (see polyfill's code).

[ttypic]

LGTM

[lawrence-forooghian]

Continuing our conversation on Slack where I asked why you'd switched web’s output type from ArrayBuffer to Uint8Array.

You said that going back and forth between Uint8Array and ArrayBuffer is error-prone because you have to make sure to remember to use byteOffset and byteLength when accessing a Uint8Array’s underlying storage. Fair enough, but I guess that could be solved by just having a method in BufferUtils for converting a Uint8Array to an ArrayBuffer and making sure that we always use it?

In terms of what's the more "correct" type to use, you said that using Uint8Array makes it more consistent with Node’s Buffer, which is a subclass of Uint8Array. Fair enough, although it does seem like that, out of ArrayBuffer and Uint8Array, the web platform usually uses ArrayBuffer as its binary data type — see, e.g. WebSocket’s binaryType property or SubtleCrypto’s exportKey. MDN’s documentation for ArrayBuffer also says "The ArrayBuffer object is used to represent a generic raw binary data buffer", which sounds like what we want.

Just some thoughts, will leave it to you to decide what to do 🙂

[VeskeR]

I guess that could be solved by just having a method in BufferUtils for converting a Uint8Array to an ArrayBuffer and making sure that we always use it?

Agree, I thought about this yesterday after your comments and started leaning towards this approach as well.
It will achieve the same goal and additionally ensure that if the consumer of the BufferUtils gets an array, they won't be able to access its .buffer property incorrectly (without using byteOffset and byteLength), as there is simply no such property on ArrayBuffer (and this could happen if we return Uint8Array from BufferUtils).

I'll go ahead and change it so we always convert to ArrayBuffer using the dedicated method which knows about byteOffset and byteLength.

[VeskeR]

@lawrence-forooghian Updated PR to always convert to ArrayBuffer using dedicated method in a20f20b