[#IP-275] Managed service preferences before message creation

[michaeldisaro]

List of Changes

• Added checks for user's services preferences during the message creation activity

Motivation and Context

We want to create messages only for users that allow to be reached, and return a coherent blockedInboxOrChannels based on preferences if they are present.

How Has This Been Tested?

It has been tested by performing:

• yarn install --frozen-lockfile
• yarn build
• yarn lint
• yarn test

Types of changes

• Chore (nothing changes by a user perspective)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[pagopa-github-bot]

	Warnings
⚠️	Please include a Pivotal story at the beginning of the PR title (see below).

Example of PR titles that include pivotal stories:

• single story: [#123456] my PR title
• multiple stories: [#123456,#123457,#123458] my PR title

Generated by 🚫 dangerJS

[gquadrati]

LGTM

[balanza]

The code seems to work as expected, anyway by a reviewer perspective is hard for me to focus on differences because the whole activity has been refactored. I'm afraid I cannot spot eventual bug/regression/edge-case we may have included in those changes.

To help on this I rewrote the test suite so that is easier to figure out which scenario we're testing and which we're not. So far I just replicated tests we used to have, and group such in three families: successes, failures and exceptions.

Changes are in 7e98711

[michaeldisaro]

The code seems to work as expected, anyway by a reviewer perspective is hard for me to focus on differences because the whole activity has been refactored. I'm afraid I cannot spot eventual bug/regression/edge-case we may have included in those changes.

To help on this I rewrote the test suite so that is easier to figure out which scenario we're testing and which we're not. So far I just replicated tests we used to have, and group such in three families: successes, failures and exceptions.

Changes are in 7e98711

Refactoring happened mainly to avoid linting errors due to too much parameters in function signature. Other refactoring happened to extract the old code and make the logic more understandable.

Your test refactoring seems legit.

[BurnedMarshal]

LGTM