Fix accounting for how many records should be indexed using index filter option "bundle filter"

Oh, damn, you're right! I didn't think about that at all, items marked as "indexed" don't necessarily have to be on the server!
I guess there's really no (feasible) way around that problem, so we should just remove the feature again, or at least the warning in this specific case (i.e., "too few" items indexed).
Patch attached, please review!

Yes, you can use it still, please tell me if it works for you. The test failures just mean I forgot to update the tests, the patch should work fine.
Here is an updated patch, though, which should also pass the tests.

So the problem is that we can't predict which items go to the index regardlessly of the fact that they could be marked as "to be indexed"? I guess it's too hard to keep track of the amount we index and compare that to the index size so I can see there's an issue here. However, this was added as a check for older versions of search api where there was no guarantee if your update actually worked and it would not retry.

So now we only show the message if on server > the amount we think we need to index? That is also not super helpful because you could share the index with other software etc. I suppose it's ok but the original reason was to figure out if there were index operations that have occurred that did not succeed in transmitting the documents to the server.

Perhaps we have to completely rip the "diverged" notification and just show the raw numbers with some explanation on how to interpret the numbers?

However, this was added as a check for older versions of search api where there was no guarantee if your update actually worked and it would not retry.

That's only true for delete operations, not for indexing, so in case of such errors the server count will be higher than it should be – which is exactly what we're catching with the current warning.

So now we only show the message if on server > the amount we think we need to index? That is also not super helpful because you could share the index with other software etc.

Sharing the index shouldn't be any problem, that's why we have the index_id field after all.
However, there are of course situations where you are using Search API Solr (or, more likely, Sarnia) only for searching while the indexing is done by some external software. In such cases, the "total items" we know of will usually be 0 (unless an integration module used for the external searchin capabilities takes extra care to determine a correct count – which isn't necessary for any other purposes, though), so we would always show that warning to the user as long as there are items indexed on the server. While not a very popular use case, I think it's probably still too important to just ignore.
A workaround might be to also skip the warning if $total_items is 0. Or otherwise, as you say, just rip it out altogether and leave the user to interpret the number for their respective setup.

OK, since not even the "count to high" heuristic will always be reliable (mostly when indexing items externally) and could furthermore give the wrong impression that this will also warn about other things going wrong, I now removed that warning, too. It will now always just display the item count, but now linking to a short explanation about its meaning/interpretation.
I think this is the best solution and hope you will agree.
(Although that's far from ideal, I will probably have to commit this tomorrow since I want this patch in the 1.11 release.)

Committed.