Feature: Add new endpoint to list message hashes

[aliel]

Self proofreading checklist

• Is my code clear enough and well documented
• Are my files well typed
• New translations have been added or updated if new strings have been introduced in the frontend
• Database migrations file are included
• Are there enough tests
• Documentation has been included (for new feature)

Changes

Add /api/v0/messages/hashes to retreive messages hash item

How to test

# curl -s http://127.0.0.1:4024/api/v0/messages/hashes?pagination=10&page=2&status=processed&start_date=1734355062&sort_order=-1&hash_only=0
# or
curl -s http://127.0.0.1:4024/api/v0/messages/hashes
{
  "hashes": [
    "1ca7aecd5....",
    "...;"
    "11517a0a5...."
  ],
  "pagination_per_page": 20,
  "pagination_page": 1,
  "pagination_total": 5093053,
  "pagination_item": "hashes"
}
#
curl -s http://127.0.0.1:4024/api/v0/messages/hashes?pagination=2&hash_only=0
{
  "hashes": [
    {
      "status": "processed",
      "item_hash": "09a6ef....",
      "reception_time": 1734355052.813517
    },
    {
      "status": "processed",
      "item_hash": "a0a01...",
      "reception_time": 1734355040.583691
    }
  ],
  "pagination_per_page": 2,
  "pagination_page": 1,
  "pagination_total": 5093067,
  "pagination_item": "hashes"
}

[nesitor]

As I understand, this new endpoint is to obtain just the item_hashes between some dates or by status, but why don't integrate it on the same /messages endpoint only adding this new hash_only parameter?
Or maybe I'm missing another functionality that we don't integrate in the other endpoint?

[nesitor]

Okay, if it's more performant because we return so little amount of fields and it's needed for this use case, LGTM 🚀

[Psycojoker]

It would have been nice to have at least a basic test for this view