presence: Add history_limit_days param to the API.

This param allows clients to specify how much presence history they want
to fetch. Previously, the server always returned 14 days of history.
With the recent migration of the presence API to the much more efficient
system relying on incremental fetches via the last_update_id param added
in #29999, we can now afford to provide much more history to clients
that request it - as all that historical data will only be fetched once.

There are three endpoints involved:
- `/register` - this is the main useful endpoint for this, used by API
clients to fetch initial data and register an events queue. Clients can
pass the `presence_history_limit_days` param here.
- `/users/me/presence` - this endpoint is currently used by clients to
update their presence status and fetch incremental data, making the new
functionality not particularly useful here. However, we still add the
new `history_limit_days` param here, in case in the future clients
transition to using this also for the initial presence data fetch.
- `/` - used when opening the webapp. Naturally, params aren't passed
here, so the server just assumes a value from
`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns
information about this default value in page_params.

api_docs/changelog.md

@@ -20,6 +20,17 @@ format used by the Zulip server that they are interacting with.
 
 ## Changes in Zulip 10.0
 
+**Feature level 288**
+
+* [`POST /register`](/api/register-queue):
+  A new `presence_history_limit_days` parameter can be given, instructing
+  the server to only fetch presence data more recent than the given
+  number of days ago.
+* [`POST /users/me/presence`](/api/update-presence):
+  A new `history_limit_days` parameter can be given, with the
+  same meaning as in the `presence_history_limit_days` parameter of
+  [`POST /register`](/api/register-queue) above.
+
 **Feature level 287**
 
 * [Markdown message