clone from RIA store (kinda) fails with invalid TMPDIR

[bpoldrack]

A user reported an issue where she wouldn't be able to get a subdataset resulting in:

[INFO   ] Fetching 'http://store.datalad.org/d3f/a72e4-2c2b-11ea-948f-0025904abcb0/config' 
[ERROR  ] FileNotFoundError([Errno 2] No such file or directory: '/tmpstore/datalad_temp_9lpj5jqp') (FileNotFoundError) 

Turns out she had an invalid TMPDIR=/tmpstore. The call succeeded on second try, though and it looked like it would behave differently when called with DEBUG logging.

Culprit is: clone is putting the content of the store's config into a tempfile in order to let a call to git config parse it. This is happening post-clone, so the actual cloning has already succeeded, explaining the observed differences in behavior. However, this partial success is not recognizeable to the user.
Moreover, the need for the tempfile is questionable to begin with, as this comment in the code states:

# TODO: We might be able to spare the saving to a file.
#       "git config -f -" is not explicitly documented but happens
#       to work and would read from stdin. Make sure we know this
#       works for required git versions and on all platforms.

So, two things need to be done, from my POV:

1. Make sure we don't crash in a postclone routine, obfuscating the fact that we already succeeded with the cloning (or crash but then clean up the clone)

2. As the comment says: If we can confirm this to work reliably, we should switch and not bother with a tempfile at all.

[yarikoptic]

I would not rely on a system/setup which "seemingly works" with an incorrect setting of TMPDIR. I would not mind avoiding tempfiles though, but as far as original issue, IMHO it is a user-error.

[bpoldrack]

It is a user-error, but it's unclear to the user what happened (we actually installed the subdataset despite the command failing) and what didn't (setting up a potential ORA remote properly).

[yarikoptic-gitmate]

Issue fixed in 0.17.10