Properly handle native queries with SpEL

[gregturn]

The following repository definition:

public interface EmployeeRepository extends JpaRepository<Employee, Long> {

	@Query(value = "select * from #{#entityName}", nativeQuery = true)
	List<Employee> custom();
}

...wil fail.

We have code that will explicitly switch it from native to non-native, and hence force it into one of the query parsers, which will cause it to fail.

However, it's not as simple as simply retaining the nativeQuery value. It also causes the QueryEnhancerFactory to kick in before parsing the SpEL expression inside. Tools like JSqlParser will fail. Thus, we need to detect it's SpEL nature sooner and properly mark it, so it's handled correctly.

This PR alters the visibility of a couple private items, but only makes them package-private.

[mp911de]

Generally, this PR isn't fitting to our existing code. AbstractStringBasedJpaQuery already creates a ExpressionBasedStringQuery that we IMO should render properly to avoid downstream issues.

Adding more context to a DeclaredQuery factory adds more dependencies that aren't within the actual scope of the query wrapper.

We should rather eagerly render the query so that downstream components work with the already resolved expressions.

[mp911de]

This method signature introduces a cycle as JpaQueryMethod uses DeclaredQuery already. Why don't we resort to EntityInformation as parameter?

[gregturn]

I have tweaked that method signature to instead pass in JpaEntityMetadata.

[gregturn]

Generally, this PR isn't fitting to our existing code. AbstractStringBasedJpaQuery already creates a ExpressionBasedStringQuery that we IMO should render properly to avoid downstream issues.

The problem is that our current flow of processing a query simply doesn't get that far before it tries to extract the QueryEnhancer, which causes JSqlParser to break on the SpEL expression.

I'm actually trying to get in front of the call to QueryEnhancerFactory.forQuery("select * from #{#entityName}") and slide in an ExpressionBaseQueryParser. So yes, it is a little hacky. Let me re-read the code a little closer, and maybe I can restructure things such that we do this overall process sooner, or at least delay finding the QueryEnhancer for a given query until AFTER we have established what type of query it is.

[gregturn]

@mp911de I drafted an alternative solution over at #3145 that is much less intrusive. What do you think?