If my measurements are correct, this change, together with the new MetadataCollection<T>, improves performance of materialization in the repro project by roughly 35%. It looks kind of "hacky" but there doesn't seem to be a better option, short of re-designing some of the structures/functionality.

TakeSnapshotOfForeignKeys() uses the metadata heavily, going from C space AssociationType space to O space AssociationType and viceversa, and trying to find the association set corresponding to an association type and an end entity set. The last one is actually a linear iteration through all base entity sets in the container. These operations are done for every single entity being materialized. This change optimizes them by storing references to association types and association sets in a way that allows for faster lookups.

RelationshipManager.GetRelationshipType is called to determine the O space association type corresponding to a C space association type. When the method is called for the first time the code iterates through the association types in C space (read-only), assigns them indices and stores the references into the MetadataOptimization._csAssociationTypes array. As the corresponding O space association types are discovered/created they are stored into the similar MetadataOptimization._osAssociationTypes array after the corresponding index (from the corresponding C space association type) is assigned. Subsequent operations that require going from C space to O space and viceversa simply do array access.

Finding an association set corresponding to an association type and an end entity set is optimized similarly, by first building an array of association sets corresponding to the association type with the same index, and then doing array access. An element of MetadataOptimization._csAssociationTypeToSetsMap can be null, an AssociationSet or an array of AssociationSets (for MEST scenarios) hence the type object[].

To be able to integrate this with the existing implementation I had to refactor some of the existing methods in RelationshipManager, RelatedEnd mainly by adding overloads and moving common functionality into helper methods.

It is possible to get some smaller gains if optimizing further (for example having two MetadataOptimization.FindCSpaceAssociationSet methods with similar implementation, instead of one with a Predicate will yield about 2-3% speed increase), but not sure if worth pursuing.
This change optimizes existing functionality without changing the main logic. It may be possible to achieve bigger gains by revisiting the overall design, but not sure how much time that would take.
Removing hardcoded AssemblyInfoVersion test. This is now covered by the RuntimeViabilityChecks
ModelBuilderEngineering - Adding CodeFirstModelBuilderEngine

In CodeFirstModelBuilderEngine we just need to validate the model in the ProcessModel override.
Overcast - changing ModelBuilderSettings to expose base ModelBuilderEngine which requires upcasting the instance to EdmxModelBuilderEngine in edmx workflows.
SilenceBeforeT4 - plumbing to support CodeFirstFromDataBase in ModelObjectItemWizard
Too much of a good thing... (2021: Throw better exception when navigation property implements ICollection<T> more than once)

The setup is that the navigation property is declared as a type that implements ICollection twice—once for a concrete type and once for an interface that is implemented by the concrete type. For example:

public interface IRole
{
}

public interface IRoleCollection : ICollection<IRole>
{
}

public class RoleCollection : List<Role>, IRoleCollection
{
}

public class Role : IRole
{
}

We currently don't support this although it might be possible to do so in the future. For now the change is just to throw a better exception message when such a model is used.
DemoVersion - plugging in T4 templates for generating CodeFirst model from DB - prototypish quality only
We were comparing IncludeLocalizedArtifacts against 'True' instead of 'true' - so we were not including localized NuGet .resources DLLs and ItemTemplates
OneEF: Fix compile errors in generated VisualBasic code
GettingOrganized - Fixing a bug where Code First items (both - empty model and from DB) were always added to the top level of the project hierarchy
Change release version and name in the release-6.1.0-beta1 branch
Remove non-public doc comments from DataRecordObjectView
Updating FwLinks for Beta1 release
Checking in FwLinks to CodePlex site for license and project - applies to master branch only
This a potential fix for #826. Other options exist but they involve a bigger change.
ConstantTranslator is unable to translate null to a DbNullExpression because it requires a type usage, which is not available for DTOs because they are not EDM types (don't exist in the model). The fix handles null values in the ConditionalTranslator by inferring the type usage from the "then" or "else" expression that is not null.
This change only fixes the problem reported in the bug. There might be other scenarios where nulls need to be handled separately.
Added change from Diego to take care of the Web API scenario. The change practically removes the restriction on RowType that made it invalid for IsNull expression.
Added new Rule to simplify the CASE statement that is generated.
This a potential fix for #826. Other options exist but they involve a bigger change.
ConstantTranslator is unable to translate null to a DbNullExpression because it requires a type usage, which is not available for DTOs because they are not EDM types (don't exist in the model). The fix handles null values in the ConditionalTranslator by inferring the type usage from the "then" or "else" expression that is not null.
This change only fixes the problem reported in the bug. There might be other scenarios where nulls need to be handled separately.
Added change from Diego to take care of the Web API scenario. The change practically removes the restriction on RowType that made it invalid for IsNull expression.
Added new Rule to simplify the CASE statement that is generated.
Tweedledee and Tweedledum... (2033: IDbDependencyResolver.GetServices not called for IDbInterceptor in latest 6.1 builds)

The problem here was that making Loaded an interceptor resulted in a circular dependency. That is, interceptors need to be requested before Loaded is called so that Loaded interceptors are obtained and can be executed, but if calling Loaded adds new interceptors then these will be missed. The fix is to ask for interceptors again after Loaded has been called and register any new ones at that time.
Merge branch 'release-6.1.0-beta1'
Adding support for string.Concat and .ToString
+("Concat", "ToString") - polishing the .Concat/.ToString pull request from Roger Alsing