HTTP middleware implementations can result in the Request object being null in S3fsStream.php

Problem/Motivation

When HTTP middleware implemtations make calls for defined routes via calls like

/**
  * Route provider.
  *
  * @var \Drupal\Core\Routing\RouteProviderInterface
  */
protected $routeProvider;

public function handle(Request $request, $type = self::MASTER_REQUEST, $catch = TRUE) {
...
  $matched_collection = $this->routeProvider->getRouteCollectionForRequest($request);
...
}

this results in the \Drupal::request() object being null in S3fsStream.php, which throws an error and causes a WSOD.

The attached patch first checks if the Request object is available before checking if HTTPS request should be forced. The approach taken in this patch is probably not ideal, because the null Request object means the S3 requests will be implicitly done over HTTP, but the module's settings allow HTTPS to be forced for all requests as a workaround.

This wasn't a problem for my particular project until #3180682: https not correctly detected in S3fsStream class made it into the latest release. Now the module relies on having the Request object available where it did not previously.

Steps to reproduce

1. Enable s3fs
2. Use the module to upload an image to S3
3. Create an HTTP middleware that calls $matched_collection = $this->routeProvider->getRouteCollectionForRequest($request);. See BanMiddleware.php for the basic middleware pattern: https://api.drupal.org/api/drupal/core%21modules%21ban%21src%21BanMiddle...
4. Clear cache
5. Go to a page where the S3 file upload is referenced, such as /admin/content/files

Here, you'll see a WSOD.

Proposed resolution

Ideally, determine if there's a way to prevent S3fsStream::__construct() from being called when route definitions are requested.

Remaining tasks

TODO

User interface changes

Probably none.

API changes

Maybe some.

Data model changes

Probably none.