fix(script): warn at startup about settings that use a missing script engine

[marevol]

Problem

Found while verifying the 15.8 → 15.9 upgrade path: a ZIP upgrade that follows the upgrade guide, on the same OpenSearch, without fess-script-groovy.

Groovy has shipped as a plugin since 15.9 (#3425), and an upgrade does not rewrite anything stored in the index:

• The startup bulk load of fess_config.scheduled_job only creates documents that do not exist yet (OpType.CREATE in SearchEngineClient), so all 14 bundled jobs keep script_type=groovy.
• A web or file config, data config or document boost rule saved before 15.9 has no script type, and an unset type means groovy (CrawlingConfig#getScriptType, AbstractDataStore#getScriptType, DocBoostMatcher).
• A 15.8 fess_config.properties carried over in Step 3 of the guide keeps job.default.script=groovy.

All of these fail only when they run, and the startup log does not mention groovy at all:

Setting	Without the plugin	Where it shows up
groovy scheduled job	fails on every run: groovy is not found. ... A plugin may be missing, such as fess-script-groovy for groovy.	the job log. But 9 of the 14 bundled jobs have job logging off, so for them only a Failed to execute job warning in fess.log
web/file config with field.script.*	indexes no documents while the crawl job reports ok	failure URLs with ScriptEngineException
data config with a handler script	values that are not a bare parameter name cannot be evaluated	at crawl time
document boost rule	boosts nothing	one warning in the crawler log when the rule is first evaluated (#3412)
groovy: path mapping	maps nothing	a warning when the mapping is first used
job.default.script=groovy	new jobs default to groovy	nowhere

Change

MissingScriptEngineReporter (new, org.codelibs.fess.helper) runs once from AllJobScheduler#schedule. At that point the DI container has started, so every script engine plugin has registered, and no job has run yet. The job scheduler is started by LastaPrepareFilter, so the check runs in the web application only, never in the crawler or other child processes. It runs again only when the scheduler is rebooted by a configuration reload, such as restoring a backup.

It loads, one bounded query per kind (the existing page.*.max.fetch.size limits):

• scheduled jobs, using ScheduledJob#getScriptType
• web and file configs that have a field.script.* parameter, using CrawlingConfig#getScriptType
• data configs that have a handler script, using script_type with an unset value counted as groovy
• document boost rules, using the same resolution as DocBoostMatcher
• path mappings whose replacement prefix is groovy: or javascript: (PathMappingHelper.SCRIPT_ENGINE_NAMES)
• job.default.script

For every engine that ScriptEngineFactory#hasScriptEngine does not know, it logs one warning. For each kind of setting the warning gives a count and up to three names (ids for boost rules and path mappings). It names the plugin in the wording ScriptEngineFactory already uses, and says where each kind takes javascript instead. On an index written by 15.8.0:

WARN  Settings use the script engine groovy, which is not registered, so their scripts cannot run: scheduled jobs=15 [Default Crawler, Suggest Indexer, Log Aggregator, ...], web configs=1 [legacy-web], file configs=1 [legacy-file], data configs=1 [legacy-data], document boost rules=1 [<id>], path mappings=1 [<id>], properties=1 [job.default.script]. A setting without a script type uses groovy. A plugin may be missing, such as fess-script-groovy for groovy. To use JavaScript instead, rewrite each script and set javascript as its script type: the Execution Method of a scheduled job, the Script Type of a document boost rule, config.script.type=javascript in the Config Parameter of a web or file config, script_type=javascript in the Parameter of a data config, the javascript: prefix of a path mapping Replacement, and job.default.script in fess_config.properties.

The check never throws. If a kind of setting cannot be read, it is skipped and the failure is logged at debug, and the other kinds are still reported. If every engine in use is registered, nothing is logged.

This does not repeat what #3412 and the path mapping helper log. Those warnings appear when a boost rule or mapping is first used, in whichever process uses it. This one is a startup inventory in fess.log.

A data config is counted as soon as it has a handler script. One whose values are all bare parameter names would still work without an engine, but that cannot be told apart without the data.

Verification

MissingScriptEngineReporterTest (8 tests):

• test_collect_findsSettingsWhoseEngineIsNotRegistered: groovy and unset job types are counted and a javascript job is not. A web config without field scripts, or with config.script.type=javascript, is not counted, and neither is a data config with script_type=javascript or with no handler script. A boost rule with no type is counted. Of the path mappings, groovy: is counted and https://…/$1, javascript: and function:encodeUrl are not. job.default.script=groovy is counted.
• test_collect_isEmptyWhenEveryEngineIsRegistered, test_collect_groupsByEngineName, test_summarize
• test_report_warnsOncePerEngine, test_report_isSilentWhenNothingIsMissing, test_report_skipsSettingsThatCannotBeLoaded, test_report_neverThrows

Upgrade reproduction. I installed the 15.8.0 ZIP on OpenSearch 3.8.0 and, through the admin API, created:

• a groovy job
• a web config with a Groovy field script, and one without scripts
• a file config and a data config with scripts
• a boost rule
• a groovy: path mapping, and an https://…/$1 one

Then I stopped 15.8.0 and started 15.9 on the same index, with 15.8's system.properties and fess_config.properties copied over as the guide says:

• 15.9.0-SNAPSHOT distribution of main: the startup log has one warning (the CORS notice) and no line mentioning groovy.
• The same distribution with this change: that warning plus the one above. It lists the 14 bundled jobs and the custom one, the web config with a script but not the one without, and the groovy: mapping but not the https: one.
• The same distribution with this change and fess-script-groovy installed: no warning, and the custom Groovy job runs ok with GROOVY:2.

mvn test: 7495 tests, 0 failures, 0 errors.