Emit a CE_Warning when CPLSet[Thread]ConfigOption() is called with a unknown config option, in debug mode

[rouault]

$ gdalinfo --config BAD_OPTION=TEST --debug on --version
Warning 1: Unknown configuration option 'BAD_OPTION'.

[coveralls]

coverage: 73.7% (-0.002%) from 73.702%
when pulling 9bda155 on rouault:known_config_options
into d9b65d7 on OSGeo:master.

[dbaston]

I don't know if this is a good idea, just tossing something out there. What if the CLI populates a global set of config options that have been specified. CPLGetConfigOption removes items from that set. On program exit, we check to see if the set was empty, and issue a warning with the names of config options that were specified but never used. This would avoid the need to maintain a header of known options, and also would produce a warning if a user specified an option that is known to GDAL but not applicable to their particular usage.

[rouault]

On program exit, we check to see if the set was empty, and issue a warning with the names of config options that were specified but never used.

There's actually code that essentially does that, currently protected by if #DEBUG_CONFIG_OPTIONS, but at the time I wrote it, I was nervous about the performance implications of enabling that in production builds at each CPLGetConfigOption() access. Perhaps that's a not founded worry, since calling CPLGetConfigOption() has already performance implications, and shouldn't be done in performance sensitive loops.
But more fundamentally users specifying config options that are not going to be read by the code can be OK in some use cases, for example when defining them in the GDAL configuration file (where they can apply to different type of workflows).

[dbaston]

If the behavior is opt-in (CPL_DEBUG=ON) then it would be useful to know that a config option you specified was not valid in the context you tried to use it in. (For example, writing a netCDF with BLOCKXSIZE.) If that spits out warnings for various tokens etc. that are stored in a configuration file, I think that's OK. Probably out-of-scope here, though.

[rouault]

If that spits out warnings for various tokens etc. that are stored in a configuration file, I think that's OK

believe we should only warn about things that are proven issues (specifying a non existing config option), otherwise users will dismiss the avalanche of warnings. Or there should be a GDAL_SHOW_UNUSED_CONFIG_OPTIONS option to enable that behavior.
That said there's a blind spot with this PR regarding config options specified as environment variables. I was thinking that we could warn about ones that would be in the GDAL_ or OGR_ namespaces, but didn't pursue this as part of this PR

[jratike80]

That said there's a blind spot with this PR regarding config options specified as environment variables.

But the options written into the [configoptions] section of the configuration file are checked, right?

[rouault]

But the options written into the [configoptions] section of the configuration file are checked, right?

with this PR, yes they will be checked, as they are set through CPLSetConfigOption():

gdal/port/cpl_conv.cpp

Line 2302 in d9b65d7

CPLSetConfigOption(pszKey, pszValue);