Update EntityEmbedFilter's recursion protection to match EntityReferenceEntityFormatter's and add test coverage

Quoting myself from #3052482-130: Expand EntityEmbedFilter's test coverage: test many more edge cases, change to kernel test:

So: recursive embed test coverage. Let's start.

1. \Drupal\entity_embed\Exception\RecursiveRenderingException was last touched >3.5 years ago. By a commit that says it's about something else. Without an issue. Apparently that commit moved it from \Drupal\entity_embed\RecursiveRenderingException.
2. That file in turn was renamed after another commit introduced it but named it incorrectly. (See next bullet.) Again without an issue.
3. That file in turn was introduced in a commit ~1.5 year prior, that commit said Removed dependency on entity_reference. — because apparently this is not a problem that Entity Embed encountered, it's one that it learned to protect against from the Entity Reference module and its field formatter. Again without issue. The class contained a more useful comment at that time:
   

    * Exception thrown when the embed entity post_render_cache callback goes into
    * a potentially infinite loop.
   

   … but despite that seemingly pointing to something Entity Embed-specific, it seems to have its roots in the Entity Reference module still.

4. And it actually goes back to the very first commit of Entity Embed: 48763795 Dave Reid <dave@davereid.net> on 2014-04-18! Clearly, Dave knew about this recursive rendering thing being a problem, probably from his vast experience with Drupal and seemingly having run into complex problems with entity reference field formatters :) The "without an issue" remarks are not meant as snark, but as factual observations that explain why it's hard to figure out the how and why of this and hence how to test this!

So, let's look at the Entity Reference module. It used to contain Drupal\entity_reference\RecursiveRenderingException. Also in Drupal 8 core. Not anymore though. #2404021: entity_reference formatters should be in Core removed it: rather than throwing an exception, it now just logs an error, because that avoids a broken site. And #2073753: Fix and add tests for the recursive rendering protection of the 'Rendered entity' formatter added test coverage for this, more than a year later, and it hasn't been touched since: \Drupal\Tests\field\Kernel\EntityReference\EntityReferenceFormatterTest::testEntityFormatterRecursiveRendering() — yay!

Ironically (and thankfully!) this led me to realize that Entity Embed's recursion protection is currently broken, for the same reasons EntityReferenceEntityFormatter's was broken: see #2073753: Fix and add tests for the recursive rendering protection of the 'Rendered entity' formatter. But that means I'd have to start violating an important principle of this issue: test coverage changes only, no code changes!

So created #3063398: Update EntityEmbedFilter's recursion protection to match EntityReferenceEntityFormatter's and add test coverage for that.

Next: patch.

Just landed #3052482: Expand EntityEmbedFilter's test coverage: test many more edge cases, change to kernel test.

Let's add a failing test first.

Here's a fix, that ports the exact same pattern that #2073753: Fix and add tests for the recursive rendering protection of the 'Rendered entity' formatter introduced — I'm glad we can follow an existing pattern 🙏

#4 made the minimal changes necessary; we should also port the use of the logger from #2073753: Fix and add tests for the recursive rendering protection of the 'Rendered entity' formatter.

Now the tricky try … catch structure can just disappear! That has been known to cause problems (see #3055050: Loosen EntityEmbedFilter's greedy exception capture: catch only relevant exceptions).

This is probably ready, but I'm not gonna commit it right away, I wanna look at it with a fresh set of eyes prior to committing.

You're not missing something, you're exactly right!

See #2073753: Fix and add tests for the recursive rendering protection of the 'Rendered entity' formatter for why this approach was chosen in Drupal core, because Drupal 8's render caching meant that the function call stack based recursion detection broke.

The goal is not to perfectly detect recursion (which never makes sense anyway, and core also doesn't manage to detect this reliably). The goal is to not let this crash a site.

That being said, I think it'd be reasonable to add a functional test with a node embedding itself in the "full" display mode using the Entity Embed filter in the body field. Then accessing /node/NID should assert that the entity label is present precisely 21 times (the recursion limit in the filter plus the original rendered entity).

I'll do that on Monday (or perhaps tomorrow), unless you want to :)

Fixing nits and the sole remaining coding standard: the one I introduced!

🚢