MessageStore interfaces for sorting and pagination

[LiranCohen]

Starting point for #274

Modified the DateSort enum into the following types:

export enum RecordsDateSort {
  CreatedAscending = 'createdAscending',
  CreatedDescending = 'createdDescending',
  PublishedAscending = 'publishedAscending',
  PublishedDescending = 'publishedDescending',
}

export enum TimestampDateSort {
  TimestampAscending = 'timestampAscending',
  TimestampDescending = 'timestampDescending'
}

export type DateSort = RecordsDateSort | TimestampDateSort;

This allows explicit types for Records sorting(by created or published) vs generic message sorting (by timestamp).

Currently RecordsQuery specify the default sort to be RecordsDateSort.CreatedDescending
Everything else defaults to TimestampDateSort.TimestampDescending

Either as a part of this effort or as a different PR there can be some enhancements to certain parts of the code that either look for only 1 message, or attempt to sort the message they're looking for via Message.getNewestMessage or getOldestMessage.

[LiranCohen]

I did some more thinking about what this will look like when fully implemented with level, this is what I came away with and would love your thoughts @thehenrytsai & @diehuxx.

I generalized the MessageSort type as per @thehenrytsai's suggestion, however as I was thinking about truly generalizing the implementation to be inspired by MongoDB (which accepts multiple fields, and generalized sorting of fields) I wasn't sure if that kind of overhead was really necessary.

For every type of property we are sorting by, the number of indexes grows. So for now we should really only sort by dateCreated and datePublished where they are available (currently RecordsWrite), and sort by messageTimestamp as a default for everything else.

I think leaving the interface generalized is a good idea so that we can add other higher level abstractions with different types of dateSort fields to different message types and only need to add indexes.

Also thinking about pagination, cursor based pagination started making a lot more sense within the DWN context. I think we should start there and move to offset based pagination if there is a strong demand for it, as it will also add overhead to indexing and performance that might not be necessary.

Right now I am thinking that the cursor pointer for pagination be the messageCid and I went ahead and added that to the response in RecordsQuery since authorization is stripped. This cursor applies generically to all types of data that are stored within the message store and gives us an easy way to look up index starting points given the existing indexing scheme.

Would be happy to discuss this more in depth over a call. But for now figured looking at the interface and naive implementation will be a good place to start.

[LiranCohen]

@thehenrytsai I think this is ready for a review at this point after yesterday's conversation.

I was going to add some types/properties to describe the sortable index fields somewhere, but it felt like premature optimization.

[thehenrytsai]

🥇 🎸 🚀 Long time coming!