Slight readability improvement on etag preparation for files

[why-not-try-calmer]

As of current master the e_tag property of S3ObjectVersion will evaluate to None in certain edge cases, causing Exceptions (see for example https://github.com/opengisch/qfieldcloud-private/pull/474). This PR ensures S3ObjectVersion.e_tag never lies about its type.

[suricactus]

Tried to find an explanation of a situation when the e_tag is None, but didn't find where it is. Would be interesting to share what is the situation when the e_tag is None and put it as a comment in the code.

IMO if such situation is real, we better return None than "", as we are lying whether the e_tag is present. So instead of adding the two ifs, it seems changing the return type makes more sense to me.

The above thoughts might be wrong when I see the reason when this happens.

[why-not-try-calmer]

Tried to find an explanation of a situation when the e_tag is None, but didn't find where it is. Would be interesting to share what is the situation when the e_tag is None and put it as a comment in the code.

IMO if such situation is real, we better return None than "", as we are lying whether the e_tag is present. So instead of adding the two ifs, it seems changing the return type makes more sense to me.

The above thoughts might be wrong when I see the reason when this happens.

My bad, I narrowed the issue down to its actual culprit.

[suricactus]

@why-not-try-calmer I am still not sure when the version.etag is None? It only happens when we have a delete version, which should not be the case for any installation?

[why-not-try-calmer]

Okay so thanks for showing how this in itself was not a bug. I've removed the bug label and this now boils down to a simple convenience PR.

[suricactus]

Thanks!

It turned out very strange behaviour that confirmed my suspision - you had a version about deletion of the file.