HADOOP-16644. Do a HEAD after a PUT to get the modtime.

[steveloughran]

WiP: no tests. What would a test look like? best to use some mock
to fix the remote time to always be slightly different from the local.
Or we make the clock of the S3A FS patchable, which is potentially
the most flexible.

Its unfortunate we need to do this; inclusion of the result in the put response, or, if it
is there, extraction of it, is what would work best -especially as that would guarantee
consistent read on update, the way an unversioned HEAD does not

Change-Id: I2c99752647f522991b1f89dd9c43f3a2e9b98bf5

[steveloughran]

Update: this is the wrong approach. The PUT response does include the modtime in the metadata

[steveloughran]

I've lifted the changes to the StatusProbes enum to #1601 ; that one is ready to go in, after which I'll have to fix this one up.

Proposed

• caller passes down the PutResult; if this is non-null it is used as the source of a timestamp.
• For multipart uploads we do the HEAD only, setting version + etag and update the timestamp if we get a result from the consistent version. If we get a different file, then do not retry, just carry on.

[steveloughran]

Update: put result doesn't include timestamp. unless we do a HEAD every time, this is in trouble.

I'm going to close the patch as is. If we were to revisit this it would be needed for every file and I'd make an option for some special cases (Yarn job submission) where timestamp mismatch is a blocker