[policy, no patch] Disallow using Package Manager (and therefore Automatic Updates and Project Browser) when Composer's disable-tls setting is true

Problem/Motivation

Composer has a disable-tls setting. I believe it's documented incorrectly. Rather than downgrading https requests to http, I think it can also use https requests (when PHP's OpenSSL extension is available), but not verify the SSL certificates. Failing to verify SSL certificates creates just as much of an adversary-in-the-middle vulnerability as not using https at all.

The contrib Package Manager module does not operate, and reports an error, when disable-tls is enabled. The purpose of this core policy issue is to confirm if that's the right decision for core.

In #3351190: [policy, no patch] Should Package Manager require Composer HTTPS?, we identified several reasons why someone might want to set disable-tls to true, but we think that none of those reasons warrant Drupal core's package manager supporting that:

• Someone might not have PHP's OpenSSL extension installed, but in #3364565: [policy, no patch] Make PHP's OpenSSL extension a requirement for installing and using Package Manager (and therefore, Automatic Updates and Project Browser) the decision so far is to not support that.
• Someone might not have a CA (certificate authority) root certificates bundle on their host system with which to validate certificates, but Composer covers this case by including such a bundle from Mozilla and using it as a fallback (see #3351190-18: [policy, no patch] Should Package Manager require Composer HTTPS?).
• Someone might have a CA bundle on their host system, but an out of date one that's unable to verify certificates from drupal.org, packagist.org, github.com, or other required pacakage repositories. However, in this case, they can configure Composer to use the Composer provided CA bundle instead.
• Someone might have a site using packages from a local or institutional packagist that's using self-signed certificates that can't be verified with either their host's CA bundle or with Composer's included CA bundle. However, in this case, they can add a custom CA bundle for verifying their self-signed certificates to their Composer configuration.

In other words, as far as we know, there's no legitimate reason to use disable-tls other than the expediency of not wanting to apply one of the proper solutions above. Meanwhile, allowing Package Manager to run with the disable-tls setting would expose the site to compromise with respect to the packages that don't have TUF protection (i.e., the dependencies not in the drupal/ namespace).

Proposed resolution

Retain Package Manager's existing behavior of requiring Composer's disable-tls setting to not be enabled.

Remaining tasks

Confirmation from product, framework, and release managers that it's okay for Drupal core's Automatic Updates to not run for sites that set disable-tls.