fix(gitprovider): use provided scheme for API calls

[hiddeco]

Follow up on #3320 (review)

This ensures that if explicitly defined, a connection over HTTP can still be made instead of silently enforcing HTTPS. This is particularly useful when e.g. running a self-hosted Gitea or GitLab instance in a homelab environment without a proper TLS configuration.

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	112cb33
🔍 Latest deploy log	https://app.netlify.com/sites/docs-kargo-io/deploys/67b753e9fd4ce0000852ccc3
😎 Deploy Preview	https://deploy-preview-3530.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[krancour]

This LGTM on its own, but with what I think is a safe assumption that APIs of all these Git hosting providers don't permit any unauthenticated access (or at least won't allow opening a PR without authenticating), this change might not have any practical effect unless we address #2198 also.

kargo/internal/credentials/kubernetes/database.go

Lines 82 to 90 in a8dfa34

	// If we are dealing with an insecure HTTP endpoint (of any type),
	// refuse to return any credentials
	if strings.HasPrefix(repoURL, "http://") {
	logging.LoggerFromContext(ctx).Info(
	"refused to get credentials for insecure HTTP endpoint",
	"repoURL", repoURL,
	)
	return credentials.Credentials{}, false, nil
	}

I remain of the opinion that sending credentials over an insecure protocol is playing with fire, but I've come around to the idea of an option in the chart that allows operators to opt into that, as long as it also comes with a sufficiently stern warning.

I'd be equally supportive of this PR being amended with that change or addressing it in a follow-up instead.

For now, LGTM'ing this as is on its own merits.

[hiddeco]

Will tackle credentials for HTTP in a separate PR.