Add new field nextUpdateTime to feed

[Grotax]

Summary

This is a first step to modernize the update cycle, the idea is to not fetch feeds on a fixed schedule.
feed-io provides a function to calculate the timestamp when an update would make sense.
This timestamp gets stored in the feed model now and can be used in a future PR to decide if we update a feed or not.

This is of course with feeds in mind that work like "normal" news feeds there might be special use case feeds that do not work well with this approach. But News does not claim to be the perfect solution for everything it is a feed reader and server api that helps users to consume feeds from different sources.

This also adds a new field to the API: nextUpdateTime contains a timestamp which indicates when the next update is due

{
    "feeds": [
        {
            "added": 1734689445,
            "faviconLink": "http://localhost:8090/logo.png",
            "folderId": null,
            "id": 39,
            "items": [],
            "lastUpdateError": null,
            "link": "https://nextcloud.com/",
            "nextUpdateTime": 2071387335,
            "ordering": 0,
            "pinned": false,
            "title": "Nextcloud",
            "unreadCount": 10,
            "updateErrorCount": 0,
            "url": "http://localhost:8090/Nextcloud.rss"
        }
    ],
    "newestItemId": 190,
    "starredCount": 0
}

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Changelog entry added for all important changes.

[Grotax]

@SMillerDev any idea what do about the failing tests? I tested it on my machine and the tests are fine. My system is a 64bit Manjaro though and my jq seems to know how to handle the output.

I can imagine that it fails because of 4090814535 which is bigger than max 32bit int.
It is a unique case of course since the feed we serve here in the test is far in the future.

Maybe if I print the jq version in actions I can get more information.

It worked before as string of course since those can be much longer

[Grotax]

I simply changed the date of the test to some years earlier, idk why jq in this environment can't handle 64bit numbers in theory it should be able to...

As a logical consequence at some point 32 bit clients or libraries that struggle with big numbers will have issues with this but I think they should be able to fix that.

[SMillerDev]

Thanks @Grotax, just one tweak.