Introduce NetworkConfig API

[123mpozzi]

Description

Introduce NetworkConfig with two APIs for pre-processing HTTP requests and responses.

PRs planning 📝

This PR contains the public API in typescript, and the implementation of one of the two APIs (preprocessHttpResponse).

At least three more PRs will follow. Specifically: #452 to implement the APIs in Android, #450 to implement the second API in iOS, and one to cover the API with system tests.

However, all PRs will not be merged into development until they're all ready. In fact we will use a base branch for this feature.

Changes ✍️

Typescript

Introduce the NetworkConfig API, accessible through playerConfig.networkConfig

Config definition in network/networkConfig.ts

This file contains the config type definition together with its other related types.

NetworkConfig:

• preprocessHttpRequest(type, request) => Promise<HttpRequest> to pre-process an HTTP request before the request is made
• preprocessHttpResponse(type, response) => Promise<HttpResponse> to pre-process an HTTP response before it gets into the player

Other relevant types

• Notably, HttpRequestType has been moved here from src/events.ts

Introduce Network module in network/index.ts

Handles the Network module and binds the actual native calls to JS through custom listeners.

Why a module? We need a module here because to serialise callbacks we have to call functions on a platform from the other.
Note: this is very similar to what we did for drm/index.ts, although there is no asynchronousity in those callbacks.

iOS

• Implement the network module to handle the bridging to and from JS. The bridging is used for passing the config object and running the callback on the JS side
• Add serialisers for network config types

Implementation details 🔬 (*)

The main struggle here was serialising a config object containing two APIs which are both async callbacks. We went for the following approach:

• Create a native module to make the JS code callable from native
• On native side, initialise the native configuration object by fetching the JS one (e.g. using json format)
  • The config will be initialised as an empty shell initially as the callbacks cannot be serialised directly
• Check if the wanted API is defined in the fetched json config. If so, start defining the native callback: serialise the parameters needed by the native API to a JS-friendly format (1), and call the JS method responsible of running the callback using the params
• On the JS side, the method gets the serialised parameters and applies the callback (2). Finally it gets the eventual resulting object and sends it back to the native side
• The native side can now acknowledge the fact that the callback has been called on the JS side, and hence runs any additional logic (3)

(1) In this case the API has a one of its parameter being a completion handler, which is required to finalise the pre-processing. So we also assign an identifier to the response to keep track of it. We store the completion handlers on the native side
(2) In this case, given that the callback is async, this method also handles the resolving and rejection of the promise
(3) In this case it calls the completion handler assigned to the response

Reading this additional section may be helpful for serialising callbacks in future PRs

Testing preprocessHttpResponse (iOS) 🧪

Use httpCallbacks.patch which modifies both BasicPlayback and DrmPlayback.
To test for a non-empty body field, use DRM stream samples.

However note that, in this PR, the request callback is not yet implemented, so it will not log or do anything!

And finally: don't forget to run yarn bootstrap!

Things to look for:

• fields are serialised correctly
  • not randomly null
  • values make sense
• performance is fine

Checklist

• 🗒 CHANGELOG entry

[123mpozzi]

This func has no logic with the json because, as of now, the only things to serialise inside NetworkConfig are callbacks, which have to be set up in a different way, and in their corresponding module.

[123mpozzi]

We are serialising a Data / NSData object using base64-encoded strings

[123mpozzi]

The other API will be part of an additional PR, but it will most likely follow the same pattern

[123mpozzi]

I am adding an Android reviewer to look at the public API changes in typescript files (and the changelog)