Repository URL inferrence broken for non-HTTPS repository servers

Follow-up of https://github.com/iterative/cml/pull/608#issuecomment-869881248

Under normal operation conditions, CML tries to infer the repository URL from the Git configuration instead of requiring users to specify it on each command-line invocation. Unfortunately, the code in charge of this behavior blindly assumes HTTPS as the remote URL protocol, and some self-hosted GitLab instances use plain old HTTP instead.

https://github.com/iterative/cml/blob/6c451d965aaea2ad2b1812dd2a223def9ce87739/src/cml.js#L30-L36

Ideally, the gitRemoteUrl function should check both HTTPS and plain HTTP (in that order) and return the first valid URL after issuing a network request to make sure that there is a server listening on the specified address.

let error;
for (const type of ['https', 'http']) {
  const repoUrl = stripAuth(gitUrlParse(url).toString(type));
  try {
    await fetch(repoUrl);
    return repoUrl;
  } catch (err) {
    error = err;
  }
}
throw error;

Unfortunately it’s not that easy, because the gitRemoteUrl function is being called from the constructor of theCML class, and constructors can’t be asynchronous. The only solution I can think of would be resorting to the same approach as in https://github.com/iterative/cml/issues/463#issuecomment-813351066.

_{DCLXVI #616 🤣}

[dacbd]

seems with a cursory glance at the currnet state im going to guess this is resolved.

[DavidGOrtega]

Or course we can override insecure connections. NODE_TLS_REJECT_UNAUTHORIZED will also work like we already know. The question is if we should allow it.