fix(server): use actual total in search pagination

[aabounegm]

Description

Previously, the response of /api/search/metadata included both total and count fields which were simply duplicates of one another and reflected the number of items in the current results page only, with nothing to indicate the total number of matched results.
This PR changes the total to actually reflect the total number of results that can be obtained after requesting all the pages.

How Has This Been Tested?

Tested manually by running Immich locally, adding some images to the library, and running some requests to /api/search/metadata. For example, a request with { "page": 1, "size": 4 } returns:

{
	"albums": {
		"total": 0,
		"count": 0,
		"items": [],
		"facets": []
	},
	"assets": {
		"total": 17,
		"count": 4,
		"items": [
			/* ... */
		],
		"facets": [],
		"nextPage": "2"
	}
}

API Changes

The total field in /api/search/metadata and /api/search/smart results is no longer equivalent to count.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

[github-actions]

Label error. Requires exactly 1 of: changelog:.*. Found: . A maintainer will add the required label.

[mertalev]

Unfortunately, getting the asset count is slow, particularly for large libraries. It isn't worth it for an endpoint that needs to be snappy. I do agree the total field is a bit misleading, so we could maybe remove it instead.

[aabounegm]

@mertalev But in that case, it wouldn't be possible to know how many images match the given filters unless all the pages are requested. The total can sometimes be relevant (for example, I'm trying to understand how many images I have from a particular camera model without location information).
How about if we include it conditionally, with an option like withTotal, for example (similar to the existing withExif and the other with* options)? It could default to false and be documented that it will slow the query down.

[mertalev]

There's a /search/statistics endpoint that returns the actual total and I think it makes more sense. In your case, you can fetch the count without needing to fetch any assets. From the server's standpoint, the usage pattern of calling this endpoint at the start before going through pages is also more sound - calculating the total count on each page would be a performance footgun.

[aabounegm]

I see. This endpoint didn't exist when I made the PR, but yes, it seems to satisfy the requirements of my app. In the future, I'd recommend mentioning in the documentation pages of endpoints the version of Immich in which they were added.
Also, perhaps the total field should be removed from the response of /search/metadata?