Refactor Notifications Reading for Better CLI Usage

[emmacasolin]

Revisting the Notifications domain I've realised that the reading and responding functionality could be improved. The NotificationsManager itself has 6 separate methods for reading/retrieving notifications, many of which are very repetitive and provide little to no extra functionality and/or are unnecessary abstractions.

The CLI command for reading notifications can also be simplified and extended to improve the user experience. As brought up in other issues (#188, MatrixAI/js-db#1), better indexing should be applied to the notifications domain in order to allow notifications to be searched and sorted more efficiently, and this should be extended to the CLI. The notifications displaying in the CLI is poorly designed at the moment and is more suited to a GUI. All notifications are displayed by default, and the command options provide limited value (for example being able to reverse the order of notifications in the display).

A solution to this would be to refactor the NotificationsManager to reduce the number of methods required. This should wait until after MatrixAI/js-db#1 so that indexing can be incorporated at the same time. The notifications read command should also be rethought with respect to usability. Potential features include:

• Being able to search through/filter notifications by type/content
• Only displaying a limited number of notifications at a time, with the option to see more (e.g. using a token https://docs.aws.amazon.com/wellarchitected/latest/APIReference/API_ListNotifications.html)
• A better response mechanism, especially for Gestalt Invite notifications, and the option to manually delete/mark a notification as read/unread
• Better JSON output - currently notifications are formatted for readability, however if JSON output is specified this should display only the notification type+contents+sender+timestamp etc.
• Notification schema validation can be removed from the client as this is already done on the server side
• Consider using an async generator to read notifications and refactoring notifications read as a streaming call rather than a unary call, similar to other handlers that return a list of results

[CMCDragonkai]

Changing to discussion since this isn't an achievable issue spec yet.

[CMCDragonkai]

@amydevs @tegefaulkes @aryanjassal this is updated to discussion, when we work out how things have changed in relation to the current notifications work then new issues can be created.