Restore compabibility with providers that bypass schema discovery query execution (e.g. Oracle)

[divega]

EF6 Tools 6.2 beta1 will contain an improvement that eliminates redundant parameters added for filtering in database schema discovery queries (see original fix in #41 from
@bengutt and later changes in #193).

While the main motivation for this change is to help the "Upgrade model from database" work with larger databases when using SQL Server, it should also work seamlessly with most providers.

That said, we believe that this change could have compatibility problems with certain providers if they bypass schema discovery query execution and produce the results of those queries by other means. Such providers would likely have a hardcoded assumption on the number and position of filtering parameters which this change could break.

[cincuranet]

I'm following up this CTA.

I've tested the FirebirdClient with EF 6.2.0-beta1 and Entity Framework Tools 6.2 Beta 1 on VS2015 and everything is fine. I tried one table model as well as huge 400+ tables model.

[divega]

Thank you very much @cincuranet!

[IanYates]

I asked on #185, but since it's closed I thought I should probably ask here on an open & related issue. Is EF 6.2 tooling present in the new VS 2017 Update 3 (VS 15.3) release that came out this week?

[divega]

@IanYates no, we don’t have public builds of the updated EF tools that target Visual Studio 2017 yet. We plan to make the updated tools part of an upcoming update of Visual Studio. The only way you can test this right now is with a previous version of Visual Studio.

[IanYates]

@divega - thanks. I've just set up a new dev machine. I'll grab the custom EF 6.x DLLs from my old machine's VS 2017 installation and bring them over to this new machine too. It all worked quite well - it's a shame it's taking so long to get the EF6.2 release into VS2017.
Of course I understand there are a million things to include and appreciate the ability to interact with the EF 6.x team here :)
The workaround will keep on doing its thing for me for the time being.
Cheers 🥂

[divega]

We have got word from Oracle that this change impacts ODP.NET. Here is the plan to mitigate this in 6.2 RTM:

We bring the old code path back alongside the new one.

We will add a flag so that providers can opt-in the new behavior. Likely it will be something like a new virtual SupportsParameterOptimizationInSchemaQueries method on the base DbProviderManifest with a default implementation that returns false (i.e. the flag goes in the runtime, although it affects tooling behavior).

We will change our SQL Server provider (and likely the SQL CE provider as well, cc @ErikEJ) to return true.

Any provider that desire to opt-in the new behavior will have to release an update that returns true.

Open issues:

• Can we factor things to avoid a complete duplication of the code?
• What to do in existing tests to make sure we test both paths going forward.