Make contact_info a read-only field for entities

[nicholaspcr]

Summary

OS counterpart of https://github.com/TheThingsIndustries/lorawan-stack/pull/4023

Changes

• Remove calls to contact info store in the following entities: [gateway,organization,user,application,client].
• Add contact_info GET test, matches the values in the administrative/technical contacts.

Testing

Manual test, unit tests.

Test Steps

Follow the steps below:

1. Login into Console
2. Create one of each entity: user,application,gateway,client,organization.
   2.1. The administrative_contact and technical_contact are the user who created the entity.
   2.2. Command example: ttn-lw-cli <entity> create --<entity>-id <entity_name> --user-id <user_id>
3. Perform the following steps for each entity:
   3.1. Get entity with --contact-info fieldmask. Command: ttn-lw-cli <entity> get <entity_id> --contact-info
   3.2. List entity with --contact-info fieldmask. Command: ttn-lw-cli <entity> list --contact-info
   3.3. Search entity with --contact-info fieldmask. Command: ttn-lw-cli <entity> search --contact-info
   3.4. Attempt to create an entity with a specified contact_info.
   • Contact Info should still be filled with admin/tech contacts when fetched. (same as step 3.1)

Example of an application with a different contact_info for the step 3.4:

{
  "ids": {
    "application_id": "app-1"
  },
  "contact_info": [
    {
      "contact_type": "CONTACT_TYPE_TECHNICAL",
      "contact_method": "CONTACT_METHOD_EMAIL",
      "value": "[email protected]"
    }
  ]
}

Observation:
For the user entity the ContactInfo returned is only composed of the user's primary email address.

Regressions

This removes the contact_info operations for all entities. Replacing the contact_info registry with the email_validation registry.

Notes for Reviewers

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• The steps/process to test this feature are clearly explained including testing for regressions.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.