Make sure the migrations history table is created cleanly

[ajcvickers]

The issue is that now that we discover DbSets from a context as a convention, re-using the convention-laden ModelBuilder for creating the history table also brings in types from the context.

For now, the fix merged is to remove this convention, but we may want to consider other options for building the history table.

See #16024

[bricelam]

Oh weird. I wouldn’t expect this to reference a DbContext:

var conventionSet = ConventionSetBuilder.CreateConventionSet();

How do you get a convention set for building a model outside of the DbContext?

[ajcvickers]

@bricelam Typically you get it explicitly for the provider you are using. For example:

var conventionSet = SqlServerConventionSetBuilderf.Build();

On the other hand, the one you get from D.I. is fully configured with everything for the context, including provider conventions, any plugged-in conventions (such as for proxies), and now conventions based on the DbContext type being used.

/cc @AndriySvyryd

[AndriySvyryd]

When #214 is implemented it will be easy to customize the conventions returned by ConventionSetBuilder.CreateConventionSet(), so we shouldn't use it for the history table.
At the same time #214 will introduce convention groups, so it would be possible to do something like ConventionSetBuilder.CreateConventionSet(ConventionGroup.AllExceptContextDependent)

[ajcvickers]

Current code is:

            var conventionSet = Dependencies.ConventionSetBuilder.CreateConventionSet();

            conventionSet.Remove(typeof(DbSetFindingConvention));
            conventionSet.Remove(typeof(RelationalDbFunctionAttributeConvention));

This seems fine.

[ajcvickers]

Note from triage: this could take advantage of convention classes when available, but it does not need to.