fix to use 1 chunk for empty file

Fix retrival of an empty file that is stored in a special remote with
chunking enabled.

The speculative chunk stuff caused a reversion by adding an empty list for
the empty file. Which is just wrong; the empty file is still stored on the
remote, and should be retrieved like any other file. It uses 1 chunk, so
`max 1` is the simple fix.

Sponsored-by: Noam Kremen on Patreon

doc/bugs/error_out_on_file_size_0_from_external_spec_remote.mdwn

@@ -86,3 +86,5 @@ so I do not think it is an issue of the remote (which might also have some size
 
 
 tried both 8.20211123 and  10.20220504 from debian 
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-06-09T18:05:15Z"
+ content="""
+This was broken by [[!commit dad4be97c2057db1ef3a13bb983d1701a90c9069]].
+
+For a key of size zero, `addspeculative` adds on a `[]` to the list of chunk
+key. But that causes retrieveChunks to think that it's already retrieved
+all the chunks, so it avoids doing any retrieval, so the file is not
+written. It needs to retrieve the empty key even though it's empty,
+so it can decrypt it when it's encrypted; git-annex does not special case
+empty file retrieval.
+
+Odd that testremote did not detect this. It does test with empty keys, and
+with chunking.
+"""]]