[#IP-308] add new UserDataDeleteOrchestratorV2

[gquadrati]

List of Changes

• Added new UserDataDeleteOrchestratorV2
• Added new GetServicesPreferencesActivity
• Modified UpdateSubscriptionFeedActivity
• Modified trigger to call new UserDataDeleteOrchestratorV2

Motivation and Context

In order to proper manage the subscription feed with new services preferences settings, we need to change the UserDataDeleteOrchestratorV2

How Has This Been Tested?

• Unit tests
• iomock

Screenshots (if appropriate):

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

[AleDore]

Since both UserDataDeleteOrchestrator versions share the same code for utility functions such as getProfile or setUserSessionLock or whatever else, can we try to resume these functions in a separate file in order to keep orchestrator logic clean in handlers?

[gquadrati]

Since both UserDataDeleteOrchestrator versions share the same code for utility functions such as getProfile or setUserSessionLock or whatever else, can we try to resume these functions in a separate file in order to keep orchestrator logic clean in handlers?

UserDataDeleteOrchestrator is not used anymore. We are keeping it, as we did in fn-app, just in case of need to switch back.
Since we're gonna delete it as soon as we are confident, do you think it's necessary this refactoring?

[AleDore]

Since both UserDataDeleteOrchestrator versions share the same code for utility functions such as getProfile or setUserSessionLock or whatever else, can we try to resume these functions in a separate file in order to keep orchestrator logic clean in handlers?

UserDataDeleteOrchestrator is not used anymore. We are keeping it, as we did in fn-app, just in case of need to switch back.
Since we're gonna delete it as soon as we are confident, do you think it's necessary this refactoring?

Maybe it's unnecessary you're right :)