restore old registerurl location tracking behavior

registerurl: When an url is claimed by a special remote other than the web,
update location tracking for that special remote.

registerurl's behavior was changed in commit
451171b7c1, apparently accidentially to not
update location tracking except for the web.

This makes registerurl followed by unregisterurl not be a no-op, when the
url happens to be claimed by a remote other than the web. It is a noop when
the url is unclaimed except by the web. I don't like the inconsistency,
and wish that registerurl and unregisterurl never updated location
tracking, which would be more in keeping with them being plumbing.

But there is the fact that it used to behave this way, and also it was
inconsistent that it updated location tracking for the web but not for
other remotes, unlike addurl. And there's an argument that the user might
not know what remote to expect to claim an url, so would be considerably in
the dark when using registerurl. (Although they have to know what content
gets downloaded, since they specify a key..)

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

doc/bugs/registerurl_does_not_register_if_external_remote.mdwn

@@ -102,3 +102,5 @@ so - both keys have urls, but only 123.dat one is associated with datalad specia
 
 [[!meta author=yoh]]
 [[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/registerurl_does_not_register_if_external_remote/comment_8_542bd923122ba24fe9cb14d36b97f15d._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-04-05T21:00:04Z"
+ content="""
+Guess I'll come down on the side of restoring old behavior which was
+changed w/o warning (and without the new behavior ever being documented).
+
+And on the side of user experience showing the current behavior is surprising.
+
+The future users who get surprised by the resulting inconsistency 
+of unregisterurl not unsetting location tracking will just have to
+live with it.. Sigh.
+"""]]

doc/git-annex-registerurl.mdwn

@@ -17,8 +17,8 @@ Normally the key is a git-annex formatted key. However, to make it easier
 to use this to add urls, if the key cannot be parsed as a key, and is a
 valid url, an URL key is constructed from the url.
 
-Registering an url makes content be treated as being present in the web
-special remote, unless some other special remote claims the url.
+Registering an url also makes git-annex treat the key as present in the
+special remote that claims it. (Usually the web special remote.)
 
 # OPTIONS
 

doc/git-annex-rmurl.mdwn

@@ -11,7 +11,9 @@ git annex rmurl `[file url ..]`
 Record that the file is no longer available at the url.
 
 Removing the last web url will make git-annex no longer treat content as being
-present in the web special remote.
+present in the web special remote. If some other special remote
+claims the url, unregistering the url will not update presence information
+for it, because the content may still be present on the remote.
 
 # OPTIONS
 

doc/git-annex-unregisterurl.mdwn

@@ -11,12 +11,14 @@ git annex unregisterurl `[key url]`
 This plumbing-level command can be used to unregister urls when keys can
 no longer be downloaded from them.
 
-Unregistering a key's last web url will make git-annex no longer treat content
-as being present in the web special remote.
-
 Normally the key is a git-annex formatted key. However, if the key cannot be
 parsed as a key, and is a valid url, an URL key is constructed from the url.
 
+Unregistering a key's last web url will make git-annex no longer treat content
+as being present in the web special remote. If some other special remote
+claims the url, unregistering the url will not update presence information
+for it, because the content may still be present on the remote.
+
 # OPTIONS
 
 * `--remote=name|uuid`