Add more correct type resolving for collections and maps

[Markoutte]

Description

Fixes #2571

The generic retrieving logic for collections and maps was naive. This PR improves that logic using guava type resolving to find out correct types. For every type it tries to resolve a type of returned values when calling such methods as Map.keySet, Map.values and Collection.iterator. A generic used in the returned type of those methods is a target type used for building a collection or a map.

Note, that the fix reveals another problem in the code generator. Because it uses untyped model it fails to generate a compilable test. For example, the result of fuzzing getAnyString method from the issue is follow:

    @Test
    @DisplayName("getAnyString: ")
    public void testGetAnyString() {
        Issue2571 issue2571 = new Issue2571();
        issue2571.put(((Object) "XZ"), ((Object) "abc"));

        String actual = issue2571.getAnyString();

        String expected = "XZ";

        assertEquals(expected, actual);
    }

This line issue2571.put(((Object) "XZ"), ((Object) "abc")); has syntax error because the map expects a string, not an object. @EgorkaKulikov , please, check this one.

How to test

Automated tests

New tests added:

The proposed changes are verified with tests:
utbot-java-fuzzing/src/test/kotlin/org/utbot/fuzzing/JavaValueProviderTest.kt`

Manual tests

All manual tests from collections samples should pass.

Self-check list

• I've set the proper labels for my PR (at least, for category and component).
• PR title and description are clear and intelligible.
• I've added enough comments to my code, particularly in hard-to-understand areas.
• The functionality I've repaired, changed or added is covered with automated tests.
• Manual tests have been provided optionally.
• The documentation for the functionality I've been working on is up-to-date.

[IlyaMuravjov]

If TypeUtils are used here, then I think they should be moved out of spring package, similarly to how it's done in #2584

[Markoutte]

Approved that

[IlyaMuravjov]

I was expecting that you'd add something like this to TypeUtils:

private fun resolveGenericsOfSuperClass(
    type: FuzzedType,
    description: FuzzedDescription,
    superClass: Class<*>,
): List<FuzzedType> {
    return try {
        check(superClass.isAssignableFrom(type.classId.jClass)) { "$superClass isn't super class of $type" }
        @Suppress("UNCHECKED_CAST")
        toFuzzerType(
            type.jType.typeToken.getSupertype(superClass as Class<in Any>).type,
            description.typeCache
        ).generics
    } catch (e: Throwable) {
        logger.error("Failed to resolve $superClass generics for $type, using unresolved type parameters")
        superClass.typeParameters.map { toFuzzerType(it, description.typeCache) }
    }
}

And use it like this:

val (keyGeneric, valueGeneric) = resolveGenericsOfSuperClass(type, description, Map::class.java)

But your approach should also work.

[Markoutte]

Thank you, this is much better. Fixed.

[IlyaMuravjov]

In your PR this method is only used for Maps and Collections, but we also have an IteratorValueProvider, that also needs to resolve generics.

[Markoutte]

It is not really necessary, because IteratorValueProvider accepts only Iterator class itself, so, it has no modifications that can cause a problem. But I added the same call to unify these providers.

[IlyaMuravjov]

Mostly LGTM

[IlyaMuravjov]

I think e should be logged here, since it should never be thrown if everything goes right. Also, without logging check(superClass.isAssignableFrom(type.classId.jClass)) is pretty much useless.