Formalize required fields for ParameterGenerator

[severn-everett]

There is an implicit contract for classes that implement ParameterGenerator: that they contain a constructor that accepts the arguments RandomProvider and String so that an instance of the class can be created in CTestStructure. If a class does not implement this constructor, a test that includes the class will fail with the output:

Caused by: java.lang.NoSuchMethodException: com.severett.androidxdemo.AnEnumGen.<init>(org.jetbrains.kotlinx.lincheck.RandomProvider,java.lang.String)
    at java.base/java.lang.Class.getConstructor0(Unknown Source)
    at java.base/java.lang.Class.getConstructor(Unknown Source)
    at org.jetbrains.kotlinx.lincheck.CTestStructure.createGenerator(CTestStructure.java:210)
    ... 90 more

As such, either the interface ParameterGenerator should be converted into an abstract class with the required constructor so that the developer can be aware of the requirements for their custom generator classes or the interface should be modified so that it requires the expected fields.

[ndkoval]

Hi @severn-everett! May I aks you why you need custom parameter generators? We are now designing a new, better API, and this information would help a lot.

[severn-everett]

Enum classes, basically. I wanted to modify the MultiMapTest example to work with tests that would pass in an enum value for the key instead of an integer. I could do that with an IntGen and obtain the randomized enum value via AnEnum.values()[i], but 1) I wouldn't be able to configure the IntGen range in a secure way - the range that gets passed in is a string in the annotation, and that requires a compile-time constant, so passing in AnEnum.values().size won't work - and 2) it would pollute the testing functions with test setup code.

A side-note: does this mean that the generator classes are going to be refactored? I was thinking of converting them to Kotlin to improve dogfooding for the project, but if there's a better place to concentrate my efforts on, please let me know.

[ndkoval]

I've created an issue to support enum classes properly; please see #186.

does this mean that the generator classes are going to be refactored?

We are working on a new API. We are still designing the part related to parameter generation, but the current API will become deprecated anyway.