Documenting the supported S3 API surface

[ad-m]

As mentioned in #623 our aim is to create feature table documenting the supported S3 API surface.

I open this issue to discuss what possible approaches we have to this problem, to solve the problem in an effective way.

One approach could be to prepare a compatibility table that would reference our tests. Then future updates would automatically refresh compatibility tables.

Adaptation of Ceph tests in our CI system could be a step in this direction: https://github.com/ceph/s3-tests

What other ideas are better than manually updating the table, which - in the long run - will probably stop working quickly?

[kherock]

@ad-m Ceph's tests look interesting! I think it could help a lot. I haven't thought of any really detailed approaches for the table other than probably modeling it off of our test suite. At a high level S3's API is quite finite and I'd be content with just marking endpoints as one of "Good support ✔" "Incomplete support 🚩" or "Unsupported ❌", though I totally agree that it wouldn't be a maintainable strategy in the long run.

The primary goal I had is to simply document what S3rver doesn't support since we're approaching a point where that info is more useful than just the list of what is mostly supported.

[ad-m]

I would like to point out that AWS offers structured API documentation as part of the "aws-sdk-js" repository: https://github.com/aws/aws-sdk-js/tree/master/apis (see files s3-*.json).

AFAIR API documentation is not available in any API or seperate repository. For comparison, such information is available in Google via the Google Discovery API and in Azure via
Azure/azure-rest-api-specs.