minor #18828 Update associations.rst (fishbone1)

This PR was submitted for the 6.4 branch but it was merged into the 5.4 branch instead.

Discussion
----------

Update associations.rst

Added caution block that informs about the risks of generated convenience "add" and "remove" methods on the inverse side.

We wasted hours for debugging an "Out of memory" error. In our case we have emails that are connected to users who can access those emails (many-to-many). There is a very large amount of emails. The memory was exceeded when we called `$email->addUser($user)` because the generated code checked if the user already has that email.

<!--

If your pull request fixes a BUG, use the oldest maintained branch that contains
the bug (see https://symfony.com/releases for the list of maintained branches).

If your pull request documents a NEW FEATURE, use the same Symfony branch where
the feature was introduced (and `6.x` for features of unreleased versions).

-->

Commits
-------

2f88c8c Update associations.rst

Author: OskarStark

doctrine/associations.rst

@@ -644,6 +644,15 @@ also generated a ``removeProduct()`` method::
 Thanks to this, if you call ``$category->removeProduct($product)``, the ``category_id``
 on that ``Product`` will be set to ``null`` in the database.
 
+.. warning::
+
+    Please be aware that the inverse side could be associated with a large amount of records.
+    I.e. there could be a large amount of products with the same category.
+    In this case ``$this->products->contains($product)`` could lead to unwanted database
+    requests and very high memory consumption with the risk of hard to debug "Out of memory" errors.
+
+    So make sure if you need an inverse side and check if the generated code could lead to such issues.
+
 But, instead of setting the ``category_id`` to null, what if you want the ``Product``
 to be *deleted* if it becomes "orphaned" (i.e. without a ``Category``)? To choose
 that behavior, use the `orphanRemoval`_ option inside ``Category``: