auto-init autoenable=yes

Try to enable special remotes configured with autoenable=yes when git-annex
auto-initialization happens in a new clone of an existing repo. Previously,
git-annex init had to be explicitly run to enable them. That was a bit of a
wart of a special case for users to need to keep in mind.

Special remotes cannot display anything when autoenabled this way, to avoid
interfering with the output of git-annex query commands.

Any error messages will be hidden, and if it fails, nothing is displayed.
The user will realize the remote isn't enable when they try to use it,
and can run git-annex init manually then to try the autoenable again and
see what failed.

That seems like a reasonable approach, and it's less complicated than
communicating something across a pipe in order to display it as a side
message. Other reason not to do that is that, if the first command the
user runs is one like git-annex find that has machine readable output,
any message about autoenable failing would need to not be displayed anyway.
So better to not display a failure message ever, for consistency.

(Had to split out Remote.List.Util to avoid an import cycle.)

Remote.hs

@@ -74,6 +74,7 @@ import Logs.Trust
 import Logs.Location hiding (logStatus)
 import Logs.Web
 import Remote.List
+import Remote.List.Util
 import Config
 import Config.DynamicConfig
 import Git.Types (RemoteName, ConfigKey(..), fromConfigValue)
@@ -286,7 +287,7 @@ remoteFromUUID u = ifM ((==) u <$> getUUID)
 	findinmap = M.lookup u <$> remoteMap id
 	{- Re-read remote list in case a new remote has popped up. -}
 	tryharder = do
-		void remoteListRefresh
+		remotesChanged
 		findinmap
 
 {- Filters a list of remotes to ones that have the listed uuids. -}