Fallback from controller-specific integration tests to general purpose integration tests

[IlyaMuravjov]

Description

As of this moment quite a few of controller parameter annotations and types (see #2462) are still not supported, making controller-speific tests limited in their ability to cover methods that use these annotations and types.

Hence it's desirable to introduce some sort of fallback from controller specific tests to general purpose integration tests.

Possible implementation plan (to be further discussed):

• if controller method has unsupported parameters or half of the generation time has passed and no successful executions were generated switch to generating general purpose integration tests;
• during minimization give more priority (see UtExecution.getExecutionPriority()) to controller-specific tests.

Potential alternatives

When testing controllers:

• always generate both controller-specifc and general purpose tests;
• only keep successful general purpose executions;
• prioritize controller-specific UtExecutions.

Additional context

General purpose executions can call controller methods directly in a way that is not possible via rest API (e.g. they can pass an invalid entity, while also passing BindingResult that says that there are no errors), because of that even if some general purpose test is able to increase coverage or has unique trace that still doesn't mean that we should include it.