Organization fanout_notifications option

[nicholaspcr]

Summary

Closes #6751

This the OS counterpart of: https://github.com/TheThingsIndustries/lorawan-stack/pull/4006

Changes

• Add migration
  • Add boolean column fanout_notifications to organizations table.
  • Make all rows of table have its value as true, preserves old behavior.
• Add FanoutNotifications field to organization API definition.
• Update notification registry to take into consideration the FantoutNotifications field from the organization entity.
• Update unit tests for new field in organization store.
• Add unit tests for notification_registry, revolves around the scenario where an organization is an (admin/tech)_contact.

Testing

Unit tests

Test steps

1. Create two users. (could be the admin user and an extra user)
2. Create an organization
   2.1. Add both as members.
   2.2. Add one of the users as the administrative contact
3. Create an application and set the organization as its administrative contact.
4. Create an API-KEY for the application.
   4.1. There should be only an email for the administrative contact of the organization.
5. Update organization and set fanout_notifications to true. Use ttn-lw-cli org set org-1 --fanout-notifications=true
6. Create another API-KEY for the application.
   6.1. There should be one email for each member of the organization.

Observation:
When testing it locally it is usefull to have dir as the email provider. Can be done by setting the Stack config to:

is:
  email:
    dir: ".env/emails"
    provider: "dir"
    sender-address: "[email protected]"
    sender-name: "nicholas-cristofaro"

Regressions

Notes for Reviewers

1. This does not include changes to the front-end so it only references the issue, will update the issue after this is approved.
2. Will also update the docs after the PR is approved and no longer subject to changes.

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.

[adriansmares]

LGTM. Consider adding this as a checkbox in the organization general settings, in the Console - it may not be as hard as it sounds.