removed user-contact connection

docs/developer/README.md

@@ -353,49 +353,6 @@ cf env getgov-{app name}
 
 Then, copy the variables under the section labled `s3`.
 
-## Signals 
-The application uses [Django signals](https://docs.djangoproject.com/en/5.0/topics/signals/). In particular, it uses a subset of prebuilt signals called [model signals](https://docs.djangoproject.com/en/5.0/ref/signals/#module-django.db.models.signals). 
-
-Per Django, signals "[...allow certain senders to notify a set of receivers that some action has taken place.](https://docs.djangoproject.com/en/5.0/topics/signals/#module-django.dispatch)" 
-
-In other words, signals are a mechanism that allows different parts of an application to communicate with each other by sending and receiving notifications when events occur. When an event occurs (such as creating, updating, or deleting a record), signals can automatically trigger specific actions in response. This allows different parts of an application to stay synchronized without tightly coupling the component. 
-
-### Rules of use
-When using signals, try to adhere to these guidelines:
-1. Don't use signals when you can use another method, such as an override of `save()` or `__init__`.   
-2. Document its usage in this readme (or another centralized location), as well as briefly on the underlying class it is associated with. For instance, since the `handle_profile` directly affects the class `Contact`, the class description notes this and links to [signals.py](../../src/registrar/signals.py).
-3. Where possible, avoid chaining signals together (i.e. a signal that calls a signal). If this has to be done, clearly document the flow.
-4. Minimize logic complexity within the signal as much as possible.
-
-### When should you use signals?
-Generally, you would use signals when you want an event to be synchronized across multiple areas of code at once (such as with two models or more models at once) in a way that would otherwise be difficult to achieve by overriding functions.
-
-However, in most scenarios, if you can get away with avoiding signals - you should. The reasoning for this is that [signals give the appearance of loose coupling, but they can quickly lead to code that is hard to understand, adjust and debug](https://docs.djangoproject.com/en/5.0/topics/signals/#module-django.dispatch).
-
-Consider using signals when:
-1. Synchronizing events across multiple models or areas of code.
-2. Performing logic before or after saving a model to the database (when otherwise difficult through `save()`).
-3. Encountering an import loop when overriding functions such as `save()`.
-4. You are otherwise unable to achieve the intended behavior by overrides or other means.
-5. (Rare) Offloading tasks when multi-threading.
-
-For the vast majority of use cases, the [pre_save](https://docs.djangoproject.com/en/5.0/ref/signals/#pre-save) and [post_save](https://docs.djangoproject.com/en/5.0/ref/signals/#post-save) signals are sufficient in terms of model-to-model management.
-
-### Where should you use them?
-This project compiles signals in a unified location to maintain readability. If you are adding a signal or otherwise utilizing one, you should always define them in [signals.py](../../src/registrar/signals.py). Except under rare circumstances, this should be adhered to for the reasons mentioned above. 
-
-### How are we currently using signals?
-At the time of writing, we currently only use signals for the Contact and User objects when synchronizing data returned from Login.gov. This is because the `Contact` object holds information that the user specified in our system, whereas the `User` object holds information that was specified in Login.gov.
-
-To keep our signal usage coherent and well-documented, add to this document when a new function is added for ease of reference and use.
-
-#### handle_profile
-This function is triggered by the post_save event on the User model, designed to manage the synchronization between User and Contact entities. It operates under the following conditions:
-
-1. For New Users: Upon the creation of a new user, it checks for an existing `Contact` by email. If no matching contact is found, it creates a new Contact using the user's details from Login.gov. If a matching contact is found, it associates this contact with the user. In cases where multiple contacts with the same email exist, it logs a warning and associates the first contact found.
-
-2. For Existing Users: For users logging in subsequent times, the function ensures that any updates from Login.gov are applied to the associated User record. However, it does not alter any existing Contact records.
-
 ## Disable email sending (toggling the disable_email_sending flag)
 1. On the app, navigate to `\admin`.
 2. Under models, click `Waffle flags`.