Fix: support arbitrary pre-calculated checksum values on s3

[Madrigal]

Previously, we were checking which algorithm was used before checking if there was any x-amz-checksum-... value setup on the input request. This is contrary to the expected behavior, where if someone sets x-amz-checksum-whatever, we should just use that value and pass it along to the service.

This PR moves the logic after we check for existing x-amz-checksum-... header

[lucix-aws]

Do we need to also check that the pre-provided checksum matches the algorithm set? Probably not?

[Madrigal]

Do we need to also check that the pre-provided checksum matches the algorithm set? Probably not?

I wondered the same. For a known algorithm, we could check that the algorithm matches the checksum header and do a SDK side error before sending the request. Currently we just send the values as set by the user, which I believe more closely respects what the user wants, even if that's incorrect.

I'll poke around, but we can always follow up on this. Let me know if you feel strongly about it

[lucix-aws]

consider it nonblocking

[Madrigal]

For closure, discussed internally with Java, we agree that we'll be sending both values and not doing validation on the SDK