docs(15.9): Amazon S3 moved to the fess-storage-s3 plugin

[marevol]

Merge after codelibs/fess#3427 and codelibs/fess#3428. The corrected notes describe the reporting #3427 adds; if that does not land in 15.9, the "silently" and "an empty list" wording has to come back.

The AWS SDK left the distribution in codelibs/fess#3428, so s3:// crawling and the s3 and s3_compat storage types come from the new fess-storage-s3 plugin. 36 files, all seven languages, 15.9 development trees only.

The new upgrade section follows the Google Cloud Storage one it sits beside, using each language's own sentence frames rather than a fresh translation — headings, the two install routes, the :: command block, and the closing "nothing to do if you don't use it" all come from the GCS section of that language, and the .. note:: bodies from the GCS note already on the same page.

storage.type still defaults to auto, which resolves to S3 when no endpoint is set, so the note says the storage page stops working until the plugin is installed even for an installation that never named s3 itself. It also says what survives an upgrade: storage.* lives in WEB-INF/conf/system.properties, and an existing crawler.file.protocols is not replaced.

The GCS section was wrong in three places, and this change falsifies a fourth

• "rejected as an invalid protocol" was half the story. CreateForm.paths carries @UriType(protocolType = ProtocolType.FILE), and UriTypeValidator resolves that to ProtocolHelper.getFileProtocols(), so a fresh installation does refuse to save the path. An installation that upgrades keeps its own crawler.file.protocols, so there the path is accepted and no crawler client handles it. Both are now described, because the second is the one an existing installation meets.
• "the storage page reports that no client is registered" was not true at all. AdminStorageAction.getFileItems swallowed the failure into a logger.debug line and rendered an empty file list. #3427 is what makes it report, and names the plugin.
• "Amazon S3 and S3-compatible storage stay in the distribution and are unaffected" now points at the new section instead.
• The shipped crawler.file.protocols was quoted as file,smb,smb1,ftp,s3, which #3428 makes file,smb,smb1,ftp. Corrected in the GCS section, the new S3 section, the removed-storage-protocol section, config/crawler-advanced.rst and en/config/properties.rst. grep -rn "file,smb,smb1,ftp,s3" over the 15.9 trees now returns nothing.

Verification

docutils 0.22.4 across 43 files, parsed before and after the way Sphinx parses — doctitle_xform=False, sectsubtitle_xform=False, file_insertion_enabled=False, with the conf.ini [replace] items prepended as the prolog so |Fess| resolves. 300 assertions, 0 failures.

• System messages identical per file, compared as counters with path:lineno: prefixes stripped so that line shifts do not register.
• No new unparsed markup in the rendered text. The residue that remains is exactly the two pre-existing defects: the nested literal in config/crawler-advanced.rst and the |Fess| inside bold in install/upgrade.rst.
• One document-level section per file throughout; total section count +1 on exactly the seven install/upgrade.rst and +0 on the other 36, with the expected value stated up front rather than read off the output. The added section is printed by name for each language.
• Every inline literal introduced parses as a literal node — the check that catches an inline start-string sitting against a CJK character, which docutils drops silently. 11 asserted on each install/upgrade.rst, fewer on the other pages.
• .. note:: counts up by exactly the notes added, +0 for ko/admin/fileconfig-guide.rst which has no example sections. This is what catches a mis-indented note body.
• Heading rules compared by display width, counting East Asian wide and fullwidth characters as two. The seven new headings match their titles exactly, as the seven GCS headings do. Korean pads to display width as well — Hangul is W — so its rules are padded.

Non-vacuity: 14/14. Confirmed against known-broken inputs — a literal and **bold** jammed against CJK text produce zero literal/strong nodes and leave backtick/star residue, a list-table row with one cell instead of two produces a new system message, an unindented .. note:: body produces zero note nodes and a directive error, a short heading rule is detected — and against the correct controls, which produce none of those.

Korean

ko/15.9/admin/storage-guide.rst is an earlier translation with no per-backend subsections, so its note goes after the storage-server list, and it omits the sentence about the Auto type resolving to S3 — that page never introduces the Type control, and pointing at a control the reader has not met would be worse than silence.

Still out of step there, unchanged by this PR: the overview names only MinIO where the others name Amazon S3, Google Cloud Storage and S3-compatible storage; there are no Common/S3/GCS/MinIO settings subsections, so Region, Project ID and Credentials Path are undocumented; and admin/fileconfig-guide.rst has no bucket-crawling example sections, so it carries neither the S3 nor the GCS example note. #526 skipped this file for GCS as well.

Deliberately not changed

• api/admin/api-admin-fileconfig.rst — docs(15.9): Google Cloud Storage moved to the fess-lib-gcs plugin #526 left it alone for GCS and it still lists gcs:// with no plugin note. Annotating s3:// but not gcs:// on a path-format reference would read as an inconsistency; both rows or neither.
• dev/plugin-architecture.rst — the fess-storage-* row already says what it needs to.
• admin/general-guide.rst gains the prerequisite on the S3 bullet only, matching what docs(15.9): Google Cloud Storage moved to the fess-lib-gcs plugin #526 did for GCS. Auto needs the plugin too when the endpoint is blank; that trap is carried by the upgrade note and the storage-guide note instead.

One figure is knowingly stale

install/upgrade.rst still says the ZIP drops from 438.5 MiB to 204.7 MiB, measured for the Node.js removal alone. The GCS, S3 and SSO extractions each shrink it further, so the final 15.9 number has to be measured from a built distribution before release. No guess was substituted.