Make creating test models more straightforward and revert to swallowing exceptions

[greg0ire]

In #8962, I established that
swallowing exceptions while creating model was bad because it could hide
other helpful exceptions.
As it turns out however, swallowing exceptions is really the way to go
here, because of the performance implication of calling dropSchema(). It
is possible to catch a more precise exception as well, which should
preserve the benefits of not swallowing them.

It looks like I based my grep on the comment inside the catch and today,
I found many other occurrences of this pattern, without the easy to grep
comment.

I decided to fix them as well, but in a lazier way: one no longer has to
remember to call dropSchema in tearDown() now, it is automated.

Here is the grep I used this time: rg --multiline '\} catch \(Exception \$e\) \{\n\s+\}'

TODO

• fix other 25 occurrences
• grep for dropSchema and improve tests changed in Stop swallowing exceptions #8962 as well.

[greg0ire]

@derrabus I'm requesting your review now because it's the most legible and interesting part.

EDIT: less so now that I have completed the first item of that todo list

[beberlei]

DropSchema might be a bad idea, because schema creation is so expensive except for sqlite

[greg0ire]

@beberlei I didn't check that in #8962

Once this is completed, I can rework createSchemaForModels to use exception swallowing and drop the @after method, that way we will be able to measure the difference.

EDIT: oh now it's failing because some tests create cms_user without dropping it 😞 I will have to bisect this.

[greg0ire]

@beberlei it looks like the performance loss is so big I can even "feel" it, even with SQLite. Let's revert to swallowing exceptions. I'll use a more specific exception, which should fix the issue I was aiming to fix in #8962 (I remember getting mad because the test was hiding an exception from me, which was probably from a different hierarchy that the one we want to catch).

[greg0ire]

@beberlei now that I reverted what I did in #8962: there seems to be a big performance gain (or rather, I introduce a big performance loss before 😞 ) :

• https://github.com/doctrine/orm/actions/runs/1869689952 9m26s
• https://github.com/doctrine/orm/actions/runs/1857819286 15m20s

[derrabus]

LGTM, once the doc block is fixed. The code is much more readable this way, very nice.