Do not cache ExpandedQueryExpression query plan if it's based on not cacheable query expression

[bahusoid]

Fixes #2298. Do not cache ExpandedQueryExpression query plan if it's based on not cacheable query expression

It fixes regression since 5.1 with possible execution of wrong DML query for queries with parameters list (details here)

In master branch it depends on #2299 (already merged)

And async code should be re-genarated when merging to master (as test for UpdateAsync is not generated in 5.2)

[bahusoid]

So the current issue is due to the way DML query is prepared in DmlExpressionRewriter.ConvertAssignmentsToDictionaryExpression. It adds the following Select to query:

selectPartOfUpdateQuery.Select(x => new Dictionary<string, object>()
{
{"propertyPath1", updateValue1},
....
};

The problem here is that property path is stored as string constant and our ExpressionParameterVisitor detects it as query parameter and replaces it with named parameter like p1. So cache key is generated without actual info about modified properties - same key will be generated for all properties.

[bahusoid]

I have an idea how to fix it (see bahusoid@4f0dd7a).

Instead of dictionary I generate a block of variable assignments:

var propertyPath1 = propValue1;
var propertyPath2 = propValue2;

So in cache key it's added as (Assign(propertyPath1, p1)propertyPath1) with modified property names in key. Maybe we should make this fix in 5.2 instead?

[fredericDelaporte]

This test would be better put into LinqBulkManipulation namespace I think.

[bahusoid]

I prefer to keep it here. IMHO it's very similar to PlansWithNonParameterizedConstantsAreNotCachedForExpandedQuery only for DML query. Also I think it's better to keep tests with a bit hacky reflection logic in one place (part about retrieving query plan cache).

[bahusoid]

DML test fails on master due to changes done #2229. After #2299 is merged - it's going to pass.