Bug 5093: List http_port params that https_port/ftp_port lack

[kinkie]

To avoid documentation duplication, current https_port and ftp_port
directive descriptions reference http_port directive instead of
detailing their own supported parameters. For https_port, this solution
creates a false impression that the directive supports all http_port
options. Our ftp_port documentation is better but still leaves the
reader guessing which options are actually supported.

This change starts enumerating http_port configuration parameters that
ftp_port and https_port directives do not support. Eventually, Squid
should reject configurations with unsupported listening port options.

[rousskov]

Thank you for working on improving documentation. Unfortunately, this PR has many small problems. I can fix them myself later, but if you do not want to wait, here is a brief laundry list:

1. Please proofread duplicated changes for typos.
2. Please adjust PR title prefix for consistency with other recent bug fixes. Adding ftp_port to the title and making the title more specific to PR changes is probably worth doing as well.
3. If you are sure that all unlisted options are supported, please disclose that in the PR description or GitHub comment. Otherwise, please rephrase "not supported" paragraphs to avoid an implication that the lists are exhaustive (i.e. that all unlisted options are supported).
4. Please fix/change indentation of new paragraphs to match indentation of the paragraph above them. IIRC, we have to use a single tab character here.
5. For each port, please integrate the new paragraph with the old one (above the new one) that talks about very similar things.
6. I would completely remove a stale (or somewhat inconsistent-with-PR-changes) and, IMO, unnecessary PR description.

[kinkie]

Thank you for working on improving documentation. Unfortunately, this PR has many small problems. I can fix them myself later, but if you do not want to wait, here is a brief laundry list:

1. Please proofread duplicated changes for typos.

Fixed

2. Please adjust PR title prefix for consistency with other recent bug fixes. Adding ftp_port to the title and making the title more specific to PR changes is probably worth doing as well.

I'm out of ideas on how to do it in 56 characters :
Hopefully it's better now

3. If you are sure that all unlisted options are supported, please disclose that in the PR description or GitHub comment. Otherwise, please rephrase "not supported" paragraphs to avoid an implication that the lists are exhaustive (i.e. that all unlisted options are supported).

4. Please fix/change indentation of new paragraphs to match indentation of the paragraph above them. IIRC, we have to use a single tab character here.

Corrected

5. For each port, please integrate the new paragraph with the old one (above the new one) that talks about very similar things.

Hopefully the new wording is an improvement

6. I would completely remove a stale (or somewhat inconsistent-with-PR-changes) and, IMO, unnecessary PR description.

Tried updating it, feeel free to remove it altogether.

[rousskov]

2. Please adjust PR title prefix for consistency with other recent bug fixes. Adding ftp_port to the title and making the title more specific to PR changes is probably worth doing as well.

I'm out of ideas on how to do it in 56 characters : Hopefully it's better now

I fixed the prefix and polished the rest of the title a bit. Updated PR description explains that this change does not list all unsupported parameters. Please adjust further as needed.

FWIW, Anubis-enforced commit title length limit is not 56 characters.

5. For each port, please integrate the new paragraph with the old one (above the new one) that talks about very similar things.

Hopefully the new wording is an improvement

Yes, it is. The wording, formatting, and consistency of those two updated paragraphs is still quite poor IMO, but I do not have the time to improve that text (especially given our unfortunate cf.data.pre indentation requirements!), and am not going to block this PR because of those secondary problems. It is better to add that text than to add nothing.