Registry Repository Matching Strategy Update

Following update to the latest release (0.15.0), the "unknown certificate lookup failure" error started occurring in context of an Azure DevOps Pipeline due to prior change to use Microsoft Secure Channel (!265 (merged)), to support GitHub Enterprise.

The issue has been resolved by updating firewall settings to enable access to all CA servers involved when verifying a certificate. However, external sources suggest this may be unnecessary as standard git client uses a best effort approach by default. Ultimately, it's assumed libgit2 will eventually be adjusted to relax the default behaviour, but regardless if strict certificate validation is in use, there's a greater chance of connection issues arising.

For the most part, these are caught/reported correctly, however, during a build pipeline where we retrieve the registry and need to match information with the current repository for which pipeline is being run - when there's not a direct match based on origin (when URL is changing), we rely on matching the commits. When these aren't local (generally the case where shallow clones are being used), we attempt to fetch commits from the current repository origin to determine if they exist. In this context, the "unknown certificate lookup failure" is currently being masked because we need to ignore errors which occur during the fetch, where network errors are known to occur because the commits don't exist. As a consequence, the registry information isn't matched properly, leading to scenario where the build process assumes target database is new and needs full schemas loaded (with registry checking, deployment subsequently fails because schemas do exist/have been registered already).

This implements improvements to this area so we will explicitly connect to the remote in order to distinguish/report any errors while connecting to the remote, before suppressing network errors that are known to occur due to missing commits, while performing fetch operation.