config refactoring

[DLochmelis33]

list of changes:

• remade KFuzzConfig, it now supports a) splitting properties into separate files b) granular editing via builder c) project properties
• refactored project to use the new config
• remade gradle plugin DSL to be independent and aligned with gradle docs

[FerrumBrain]

Why can't we initialize all of them? I believe that users can have settings for several engines and use one of them by specifying engine field. It might be unclear how to keep API independent on supported engines, but since we directly specify jazzer here it is ok (probably)

[DLochmelis33]

This is what Will need to be careful with instantiating delegates, as they will get validated. means here: if we try to initialize them, but properties are missing, validation will fail. I guess an alternative option is to allow some properties to remain invalid

[DLochmelis33]

If nobody objects, I will leave this as-is for the time being

[ilma4]

Maybe, we should move instrument and customHookExcludes from TargetConfig to GlobalConfig. I can't see reasons to instrument different classes depending on target (we could instrument only the code we execute, but it's a different thing). Same for customHookExcludes: if we want to exclude something, we most likely want to exclude it everywhere

[AbdullinAM]

I'm not sure that I fully agree with that. I think there might be reasons to want to instrument different parts of code for different targets. Because depending on what is instrumented, fuzzer will change its behaviour. So if I want a target to fuzz a specific part of the project, I would want to "communicate" that idea to the fuzzer

[DLochmelis33]

IMO it makes more sense to have customHookINCLUDES for some targets and others not. But this is again a question about borrowing Jazzer naming. Will remove these two from @KFuzzTest arguments as well

[ilma4]

Right now, JunitEngine doesn't depend on any concerete FuzzEngine. However, here we have JazzerConfig in the API. From my point of view, concerete FuzzEngines should be configured somehow independently from the kotlinx.fuzz in general, since we might want to change them

[DLochmelis33]

I too dislike the fact that all configs have to go into api subproject. That may be possible without ruining the syntax too much, but internal apis like KFuzzProperty will have to be made public and leak outside. In general what we are trying to do here is serialization into properties, and in order to not risk implementing our own kotlinx.serialization, I suggest keeping this as-is

[ilma4]

I think, we should rework this option

1. It doesn't "enable logging". It repeats JazzerEngine's log into console
2. It would be usefull for any FuzzEngine not just for jazzer.

So, consider moving it to global config under name like "detailedConsoleLog"

[DLochmelis33]

On that note, I think we borrowed more names from Jazzer and we might want to reconsider them too, for example instrument seems way too unclear for me just from the name

[DLochmelis33]

Let's merge this PR before any others, because it conflicts with basically everything and I'm tired of fixing merge conflicts :D

[FerrumBrain]

Based on its usage, it is more like "loggingToConsole". We log information in a file anyway, this flag just copies it to the standard output

[FerrumBrain]

Overall, it looks good to me