HTTP Cache Control needs documentation that the max_age value cannot be the same as a response code value

Attached a test + patch (not a clean patch but it... works(?)) Maybe need to check if these values are null too.

The patch doesn't work, s-maxage and max-age are always set to the same value.
The configuration form says that the 3xx/404/5xx max-age value should be the same as 200 responses. If that's the case, why is setClientTtl called?

I don't understand how the code even gets past $response->isCacheable(). That method contains the following logic:

public function isCacheable(): bool
{
    if (!\in_array($this->statusCode, [200, 203, 300, 301, 302, 404, 410])) {
        return false;
    }
    if ($this->headers->hasCacheControlDirective('no-store') || $this->headers->getCacheControlDirective('private')) {
        return false;
    }
    return $this->isValidateable() || $this->isFresh();
}

It explicitly disables caching for 404/302/301 responses, so if I'm understanding correctly the max-ages provided by this module for those status codes are never used, right?

A couple things I don't understand either about the current code:

1. Why are the 404/302/301 TTL's being assigned to the maxage, even though their setting descriptions state they are only being used for s-maxages?
2. Why is setClientTtl() used for max-ages and setSharedMaxAge() for s-maxages? The former considers the Age header, the latter doesn't.
3. Why is the s-maxage set when it's the same as the max-age?
4. Why is the configured s-maxage only used when it's > 0?

I'm afraid that fixing the first one would require a new major release. It's undocumented behaviour, but still behavior that people might depend on. I started a MR fixing 1, 2 and 3, which in turn also fixes this issue. I did keep the last one for now, but I decided to document it in the form.

Existing and new tests are passing, but it would be great if @josh waihi could review, just to make sure we're not missing anything here.