Summary:
This was originally done in #377 to support chinese characters, but it's not clear how it works, or what problem specifically it is trying to solve.

It's causing some problems where valid responses are failing to be "decoded", so I'm removing it.

Reviewed By: mweststrate

Differential Revision: D22866879

fbshipit-source-id: a19a57b0ddba2b9f434eb3c37e6b92da1dfbef01

Summary:
Changelog: [Network] Non-binary request are not properly utf-8 decoded on both iOS and Android, both when gzipped and when not gzipped

This diff fixes a long standing / ping-pong issue regarding network decoding differences between
* iOS vs Android
* binary vs utf-8
* gzipped vs uncompressed

The changes aren't too big, but the underlying investigating is :)

The primary contribution to this diff is:

First, adding test cases for know problematic cases. This is done by grabbing the messages that are send from the flipper client to flipper using the flipper messages plugin. This is the base64 data that is stored in the `.txt` files. Beyond that, for all tests public endpoints are used, so that we can both get a hold of the raw original files, and how we expect them to be displayed in flipper.

For testing a simple RN app was build, with a button that fires a bunch requests. The first 3 are captured in unit tests, the last one is not idempotent, but a case reported in #1466, so just left it there as manual verification.

```
const fetchData = async () => {
  await fetch(
    'https://raw.githubusercontent.com/SangKa/MobX-Docs-CN/master/docs/donating.md',
    {
      headers: {
        'Accept-Encoding': 'identity', // signals that we don't want gzip
      },
    },
  );
  await fetch('https://reactnative.dev/img/tiny_logo.png?x=' + Math.random());
  await fetch(
    'https://raw.githubusercontent.com/SangKa/MobX-Docs-CN/master/docs/donating.md',
  );
  await fetch(
    'https://ex.ke.com/sdk/recommend/html/100001314?hdicCityId=110000&paramMap[source]=&id=100001314&mediumId=100000037&elementId=&resblockId=1111027381003&templateConfig=%5Bobject%20Object%5D&fbExpoId=346620976471638017&fbQueryId=&required400=true&unique=1111027381003&parentSceneId=',
  );
};
```

The second contribution of this diff is that it doesn't use weird URLencoder hacks to convert base64 to utf8, but rather a proper library. The problem with our original solution, using `atob` is that it converts to ASCII, not to utf-8, which is the source of the original bugs. See for more background on this: https://www.npmjs.com/package/js-base64#decode-vs-atob-and-encode-vs-btoa-

Solves:
#1466
#1541
#1458

Supersedes D23837750

Future work: we don't inspect the `content-type=xxx;charset` header yet, which we should do for less common encodings, to make sure that they get displayed correctly as well

Future work: in feature like copy data and curl, we always call decode body, without check if we are actually dealing with non-binary data. Probably it is better to keep binary data in base64, rather than decoding it, as that will assume the data is an utf-8 string, which might fail.

An assumption in these changes is that binary data is never gzipped, which is generally correct; gzip is not applied by webserver to things like images, as it would increase, not decrease their size, and waste a lot of computation power.

Reviewed By: cekkaewnumchai

Differential Revision: D23403095

fbshipit-source-id: 5099cc4a7503f0f63bd10585dc6590ba893f3dde