Remove unnecessary "status" and "uid" fields from entities

We should get rid of the uid column. We should consider retaining the status field.

The Contact Details, email/telephone/address can all be temporarily unavailable. I can also see scenarios were the contact detail is no longer correct, but you do not want to delete it; to have a last known address/email/telephone bit also indicate that it should not be used.

I think this will be useful in more advanced features like mailing, auto dialer, or email campaign.

The Contact Relationship, I think this most of all needs the status field. In addition to having inactive relationships, e.g. past employment.

We have discussed having workflows for contacts, potentially multiple workflows on the same contact. I think the same results can be achieved by putting the workflow on the relationship.

It should be status, not active; it is a Drupalism.

I also think the contacts should have a status field. It functions as a soft delete; people die, and organizations cease to exist.

To me, "status" in Drupal represents whether content is published (e.g. EntityPublishedInterface). I think it is confusing and limiting to use "status" to mean something other than that and I don't think any of the entities in CRM conceptually get "published" or "unpublished".

An alternative for some use cases, adopted by Drupal CMS, is the Trash → module, which moves deleted content into a Trash can rather than being deleted outright from the start. This (or, more generally an "Archived" state) feels like a more modern approach that I've observed in CRMs. However, it is currently incompatible with Content Moderation (that's being worked on) and non-SQL storage backends (no evidence that's being worked on) so I'm not proposing adoption of Trash at this time.

Past employment is a great example of a useful thing to represent, but for which overloading the published "status" could cause problems. If a past employment relationship has status 0, should it not be rendered when viewing a contact? That seems very specific to a given site's needs. Relationships already have "start" and "end" timestamps, which would seem to already serve the need of identifying whether an employment relationship is in the past.

An Individual dying is a notable thing to track, but I would propose that this be tracked in a semantically named field on the Individual bundle, perhaps along with an optional date. A User might want to "archive" / soft delete a Contact independent of whether they died.

Similarly, that an Address is temporarily unavailable (maybe it's seasonal?) is a specific thing worthy of tracking more semantically.

While I'm open to the use of "status" if it's important and there's not a better solution, I'm not convinced that it's important yet and I think we should spend some more time addressing specific use cases in more semantic ways.

I propose proceeding to remove "status" as specified in the IS and opening follow-up issues for each entity that has use cases for which "status" could be used so that we select the best solution for each use case. In some cases this might be a workflow. In others it might be a field like "Dead". This will help facilitate a 1.0 release without committing to overloaded uses of "status".