don't use attrs md5 when file was gpg-encrypted by us

Since 5fc2bbcc (2013-05-20 23:31:50 -0500), the value we stored into
the s3cmd-attrs header for md5 contains the value for the plaintext,
not the encrypted, instance of the file.  But after download we're
(incorrectly) checking the md5 of the encrypted file. This patch fixes
this.

We started storing the md5 value in s3cmd-attrs header in 1703df7009
(Fri Jun 15 23:43:00 2012).  So it's likely been broken for a couple
years, and we'll have to deal with it (check both before and after
decryption I suppose, in case it matches either).  That'll be another patch.

With the new Content-MD5 branch too, calculating md5 before encrypting
is a really really bad idea - that's just broken design.  Encryption
should be done before we calculate the MD5 of the thing being
uploaded.  It was the filename swizzle that caught me off guard.