Motivation

As reported in #9076, there is an issue in the way Moto and LocalStack handles HTTP Range requests for S3. AWS is apparently not following the RFC for range requests and is very, very forgiving, as shown by the added test.

An int-range is invalid if the last-pos value is present and less than the first-pos.

As pointed out by @sjperkins who went through the RFC, the server can ignore the range header for some conditions:

A server that supports range requests MAY ignore or reject a Range header field that contains an invalid ranges-specifier (Section 14.1.1), a ranges-specifier with more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order,

Basically, if the range request is badly formatted or invalid, S3 will just treat the request as a non-range request and will return the entire object with a 200 status code.
Only certain conditions will trigger an exception and 416, mainly if the beginning of the request is above the end of the object and the request is a valid Range request (meaning it can be parsed), or if the request is a "suffix" request and it ends with 0.

Changes

This fixes the behaviour only for the v3 provider for now, I'll need to open a PR upstream in moto to fix the behaviour there to fix the default current provider. Edit: the PR upstream is already merged, so I'd like to have the v3 behaviour in line.

I might remove all the skip for the new provider tests and selectively xfail the tests for the default provider in a follow up PR, to see the extent of the issue with the current provider, and try to have some tests such as this one valid for both.

I've launched a run with this fix in the forced v3 S3 branch here, and it's green: https://app.circleci.com/pipelines/github/localstack/localstack/17924/workflows/3026ab82-afaa-4b31-9b45-fbd7afbab1bd

This also fix the behaviour for UploadPartCopy which has a very strict handling of the CopySourceRange parameter.