Add flag to disable dumping Dokka config file

[adam-enko]

Dumping the Dokka config files is useful for debugging, but can interfere with task outputs.

Here we add a flag that disables the dumping the config file by default, but we enable it for our own tests.

Fix #3958

[whyoleg]

curious: why can't we just remove @OutputFile from dokkaConfigurationJsonFile?

[adam-enko]

curious: why can't we just remove @OutputFile from dokkaConfigurationJsonFile?

why can't we just remove @OutputFile from dokkaConfigurationJsonFile but need an additional property to disable debug functionality?

Removing @OutputFile would fix #3958, but it has a downside: we would lose being able to see the config file when the task is loaded from cache, which is useful for investigating issues (especially on CI where it's harder to specifically re-run cached tasks that succeeded but produced output with errors).

[whyoleg]

Okay, I see, thanks!

The main thing that worries me is that we already have there two internal task properties (for debug purposes): dokkaConfigurationJsonFile and overrideJsonConfig. And now we add one more + one more internal Gradle property. IMO, it complicates debug configurations and look more and more like a hacks/workarounds.

WDYT about small change: create a separate intermediate task (e.g generateDokkaConfiguration*) which will generate JSON file with DokkaConfiguration and pass it as an input for dokkaGenerate* task?

1. in this case we will not have problems with outputs and caching
2. the file with JSON configuration will be always there and so users will be able to share it for troubleshooting
3. if someone (we) needs to override json configuration for dokkaGenerate* task, it will be still possible by provide custom file path with custom configuration

Yes, it looks like a bit more work, but I think that it might be worth it. WDYT?

[adam-enko]

Ah, a separate task could work, yes. I would have to investigate.

I see a problem with a generateDokkaConf* task: the config file produces system-specific output which would break remote-caching.

It might work if we made a completely separate 'debug' task that builds and logs the config file, to avoid interfering with the 'production' task.

[adam-enko]

I'll just make the property @Internal, because this is only a debug utility. It would be nice to have the file cached, but realistically that won't often be important and the task can just be --rerun.