don't force use of conduit in withUrlOptionsPromptingCreds

Use curl for downloads from git remotes when annex.url-options and other
git configs are set.

If the url needs a password, curl will fail, and git credential will not be
used to prompt for it. But the user can set --netrc in url-options and
put the password in the netrc file.

This also means that url-options settings like -4 will take effect.
That was the case before commit 1883f7ef8f
forced conduit to be used.

doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_2_599a66a1833000dc0e54a33511891b36._comment

@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-09T19:19:44Z"
+ content="""
+Confirmed this behavior.
+
+It is due to withUrlOptionsPromptingCreds, which forces use of conduit
+rather than curl. The idea there was to use git credentials when basic
+auth is needed. Since those can be provided to conduit but not to curl
+(securely).
+
+But I do think that, if the user has forced use of curl, it ought to use curl.
+Even if the user only set options to `-4`, and so curl is not going to use
+the netrc and will fail the download. I have changed it to do so.
+
+----
+
+This bug report also suggests making git-annex read the netrc file itself.
+Note that git does *not* read the netrc file itself. What it does do is use
+libcurl. git-annex has good reasons to not use libcurl though.
+
+I am not thrilled by the prospect of implementing a parser for netrc
+in git-annex. The file is not even documented on my debian system;
+curl's man page links to a `netrc(5)` but that does not exist.
+
+Aside from git-credential-netrc, there is not a single mention of 
+the netrc file in git's documentation. This is arguably surprising behavior
+on the part of git. 
+
+I feel that git's support for netrc is vestigal and mostly supersceded by
+git credentials.
+"""]]