Create the default namespace in the schema

[morozov]

This patch should address doctrine/migrations#1415.

Problem details

1. When the Postgres schema manager introspects a deployed schema, it creates the namespace with the name corresponding to the value of current_schema() in the Schema.
2. When SchemaTool generates the schema to be deployed, it doesn't create the default namespace.

As a result, we have a mismatch in the list of schemas between the "from" and "to" schemas.

Solution

Instead of the approach proposed in doctrine/dbal#5609, here, we add the default namespace obtain from the schema configuration, to the schema. This replicates the behavior of the schema manager.

Alternatives

As an option, the DBAL Schema could automatically create the namespace with the name from configuration in its constructor. There are certain difficulties with that:

1. Prior to DBAL 4, the schema configuration name is not only set to the value of the current schema for Postgres, but is also set to the name of the current database for all other databases. Implementing the fix in DBAL prior to 4.0 will likely introduce a regression for all other platforms except for Postgres.
2. Prior to DBAL 4, the schema configuration name is equal not to the current schema name but to the first value from the search path, (which by default is postgres).
3. The operation of adding a namespace to the schema is not idempotent. So if we register the namespace in the constructor, then the subsequent call to createNamespace with the same name (as the DBAL's schema manager does) will fail.

Limitations

This fix cannot be implemented in ORM 2.x which still supports DBAL 3.x, which has the issue #​2 from the above list.

[morozov]

The problem with this approach is that now the public namespace is included in the schema generated by SchemaTool but instead of using something like $schemaManager->migrateSchema($schema), the ORM generates SQL using its own code:

orm/src/Tools/SchemaTool.php

Lines 75 to 77 in 824c050

	public function createSchema(array $classes): void
	{
	$createSchemaSql = $this->getCreateSchemaSql($classes);

This leads to the fact that SchemaTool#createSchema() attempts to create the public schema in the database and fails.

An attempt to rework SchemaTool#createSchema() to use the diff leads to the problem that the diff not only contains the CREATE statements but also the ALTER and DROP ones. This way, a call to SchemaTool#createSchema() would also DROP the objects that are do not represent any entities, which is likely undesired.

Even if we filter the diff and leave only the CREATE statements, some tests will fail. Also, the approach with diff noticeably slows down the test suite, since the schema is introspected before each test.

[morozov]

The real question is, what is the meaning of the schema produced by SchemaTool?

If it's the full representation of the corresponding entities, then it should contain the public namespace (as in this PR), and it should be deployed in a differential way (which currently doesn't work).

If it contains only the resources to be deployed (as in the current implementation), then Migrations should not use it to generate the diff (because it's already a diff).

[morozov]

Closing in favor of doctrine/migrations#1463.