Allow requests to be modified in an async manner

[littlespex]

Possible solution for #3758 & #3957. The modifier can be applied via:

player.extend('RequestModifier', () => {
  return {
    modifyRequest: async (request: any) => {
      // wait for an async process
      await new Promise(resolve => setTimeout(resolve, 1000));

      // modify the request;
      const url = new URL(request.url);
      url.searchParams.append('TESTING', '1234');      
      request.url = url.toString();
      request.headers.TEST = '1234';
    }
  };
});

NOTE: Disable white space in "files changed" tab for a clearer view of what's changed.

There are a few open questions:

• I'm not sure an optional function fits with the rest of the architecture. Maybe add a separate config option?
• Should the modifyRequest function mutate the given request object, or return a it's own request?
• How does this effect timing stats? The modifier is applied before requestStartTime is recorded, so the download stats should function as they did before, but will any extra delay in the async function mess with any other calculations? If so, does it matter, or can we add a note in the docs like: "If you use async modifiers, stats may be adversely effected".

[ElasticPencil]

It feels a little odd that the request timer starts after the asynchronous modifications complete, but before synchronous. I would think this should be consistent.

[littlespex]

The idea was to keep requestStartTime specific to the HTTP transaction. I can see valid reasons for either approach.

[dsilhavy]

Agree with @littlespex here, prefer to do the modification before starting load . This would align with modifyRequestURL

[ElasticPencil]

Same as fetch loader, should the requestStartTime include asynchronous modifications?

[ElasticPencil]

There is a small performance and timing impact here by always calling modifyRequest. This gaurantees the rest of the code will occur on nextTick even when no requestModifier is supplied. Do you think it would be better to avoid this impact or are you ok with this slight change?

[littlespex]

The code has been updated to only apply the async modifier if it exists.

[ElasticPencil]

A test should be added to verify that an optional modifyRequestURL function is supported. Once this ships and people are supplying a requestModifer without this method it shouldn't regress.

[ElasticPencil]

Overall I think this is a good solution and would allow me to use this for solving the async authorization.

[dsilhavy]

@littlespex @ElasticPencil Apologies for the delay here. I am currently finishing the first implementation of content steering and I will look into this afterwards.

[dsilhavy]

Thanks @littlespex @ElasticPencil looks good to me. I added some minor comments above. One more request: Can you please modify the sample plage samples/advanced/extend.html to include this new function. Thank you

[littlespex]

Added example