refactor: [IOCOM-2800] Remove PNMessage data structure

[Vangaorth]

Short description

This PR removes PNMessage data structure

List of changes proposed in this pull request

• PNMessage was a convenience data structure to easily access a SEND message's content
• Such data were computed dynamically from in-memory stored data
• Thus, their usage had to be cached, using createSelector, since they always were a new instance
• That created side effects problems (see fix: [IOCOM-2742] SEND message details screen rerender fix #7616)

With this PR:

• PNMessage has been removed
• The selector returns the in-memory instance of the third party message. This structure has one more depth level with respect to PNMessage
• Since the third party message declares such instance as [string, any], we first check that it is indeed a ThirdPartyMessage from SEND (which is not [string, any] but has a specific data structure) and later return an explicit type assertion. This is needed in order to correctly type it as a ThirdPartyMessage from SEND but also to use the in-memory stored data, without creating a new instance. Proper guards and type checks avoid doing this on an invalid data structure
• An additional selector has been created to retrieve the creation date of the message (since it is not part of the SEND message)
• Sagas and components have been adapted to not rely on PNMessage

How to test

Using the io-dev-api-server, check that both standard and AAR SEND messages are still working and there are no additional re-renderings

[github-actions]

Jira Pull Request Link

This Pull Request refers to Jira issues:

• IOCOM-2800

[github-actions]

PR Title Validation for conventional commit type

✅ All good! PR title follows the conventional commit type.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.14%. Comparing base (f60c666) to head (a3e26d5).
⚠️ Report is 192 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #7620   +/-   ##
=======================================
  Coverage   60.14%   60.14%           
=======================================
  Files        1882     1881    -1     
  Lines       41047    41051    +4     
  Branches     9525     9448   -77     
=======================================
+ Hits        24687    24692    +5     
  Misses      16283    16283           
+ Partials       77       76    -1     

Files with missing lines	Coverage Δ
.../features/messages/saga/handleThirdPartyMessage.ts	77.55% <100.00%> (+0.95%)	⬆️
ts/features/pn/aar/store/selectors/index.ts	98.14% <100.00%> (+0.07%)	⬆️
ts/features/pn/components/MessageDetails.tsx	89.47% <100.00%> (+4.47%)	⬆️
...s/features/pn/components/MessageDetailsContent.tsx	95.45% <ø> (ø)
ts/features/pn/screens/MessageDetailsScreen.tsx	98.36% <100.00%> (+0.05%)	⬆️
ts/features/pn/store/reducers/index.ts	100.00% <100.00%> (ø)
.../features/pn/store/sagas/watchPaymentStatusSaga.ts	95.23% <ø> (ø)
ts/features/pn/utils/index.ts	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 63c8e47...a3e26d5. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[forrest57]

Suggested change

	const sendThirdPartyMessage = sendThirdPartyMessageEither.right;
	if (sendThirdPartyMessage.details == null) {
	return undefined;
	}
	return thirdPartyMessage as ThirdPartyMessage;
	const sendThirdPartyMessage = sendThirdPartyMessageEither.right;
	if (sendThirdPartyMessage.details == null) {
	return undefined;
	}
	return sendThirdPartyMessage

why not return the decoded value directly?

[Vangaorth]

Because it is a new instance that causes the same problems that the original toPNMessage did

[Vangaorth]

This PR is on Don't merge since there is a data mismatch (between string and Date) on field activeFrom (notificationStatusHistory)

[github-actions]

This pull request is stale because it has been open for 60 days with no activity. If the pull request is still valid, please update it within 14 days to keep it open or merge it, otherwise it will be closed automatically.