feat: [IOCOM-824,IOCOM-825] Loading and loaded message list adapted to the new DS

[Vangaorth]

Short description

This PR adds the message list loading and displaying, adapted to the new DS.

Empty list, Error handling, item selection, next page loading, refresh and so on will come later.

Inbox loading	Archive loading	Inbox loaded	Archive loaded

List of changes proposed in this pull request

• New MessageListItem and MessageListItemSkeleton components. These files and all the content inside the DS folder will later be moved into the design system library. They are temporarily here in order to ease the development process and changes that will come in later PRs. CustomPressableListItem will later be merged into PressableListItem. useListItemSpingAnimation is just an exported hook from the design system, used inside CustomPressableListItem, and will be later deleted.
• MessageList component have been enhanced in order to implement the FlatList displaying the message list
• New WrappedMessageListItem to encapsulate all the business and rendering logic for the MessageListItem
• New messageListForCategorySelector selector. Its output is used by the message FlatList and it is interpreted as follows:
  • undefined output means that messages are still loading
  • an empty list is used to trigger the Empy List Component in the Flat List (which will be implemented later). This component will handle both a "no messages" case and the "no messages because of an error" case.
  • a message list to display

When undefined is returned, MessageList provides a fixed list as an input to the FlatList. Such list is computed in order to have as much elements as the screen height allows, to fill the view. Its type is different from the standard message list so that the renderItem function can detect it and create MessageListItemSkeleton components instead of WrappedMessageListItem ones.

• WrappedMessageListItem uses a selector to get the service data which is used to compute the service's logo CDN urls. If service data is not available, a loadServiceDetails.request action is dispatch to load them. Since such request uses a takeEvery saga, we have to make sure not to dispatch multiple requests for the same service (since multiple messages may have the same service). This is done by checking if the service's pot is in its loading state inside the useEffect hook. This status is inside the redux state but we do not want a re-rendering to happen when the pot changes: that is why this latter data is retrieved using the store and not a selector.

How to test

Using the io-dev-api-server, make sure that both DS and new home are enabled in app. Get to the messages home and switch between tabs (in order to see the loading list with the dev server, you can set a delay function on the related router, something like 3500 milliseconds).