checkpresentkey: fix behavior to match documentation

checkpresentkey: When no remote is specified, try all remotes, not only
ones that the location log says contain the key. This is what the
documentation has always said it did.

Still try the logged remotes first, because they are far more likely to
have the key.

doc/bugs/checkpresentkey_wrongly_reports_key_absense.mdwn

@@ -82,3 +82,5 @@ upgrade supported from repository versions: 0 1 2 3 4 5 6
 local repository version: 5
 
 Linux ip-172-31-85-193 4.14.97-74.72.amzn1.x86_64 #1 SMP Tue Feb 5 20:59:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/checkpresentkey_wrongly_reports_key_absense/comment_2_0a7bb6b12a4eb49addf443db2d16553f._comment

@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-16T17:35:41Z"
+ content="""
+So I guess the problem description is:
+
+checkpresentkey with the uuid of a remote verifies the key is on the
+remote, return 1. But, with no uuid, it's supposed to check all remotes,
+and instead it seems to fail and return 0 without checking the remote
+whose uuid the earlier run of it showed does contain the key.
+
+And I think I see why it would do that. When no remote is given, it reads
+the location log, and checks each remote that the location log says
+contains the key. So, if the location log is out of date and a remote does
+contain the key, it will return 0 w/o checking it.
+
+It would probably make sense for it to actually try all accessible remotes,
+on the off chance one of them has the key. That's what the documentation
+says it does, although I don't think it ever has.
+
+The original use case for this was
+[[todo/checkpresentkey_without_explicit_remote]], and it does seem like
+that use case intended to check all remotes, not only ones the location log
+has it.
+"""]]