Remove "Search API Taxonomy Term Handlers" module

Huh, seems this is a duplicate of #2917399: Missing / broken handler when adding a filter for a field, we apparently overlooked it. At this point, really the only thing to do is removing the module, so: thanks for the patch!
We should probably still wait a bit with that, though, to give people time to disable it. But good to already have the patch prepared.
It would be great if you, or someone else, could bump this issue again in a few months (after another Search API release or two).

I don't think we can do this in the 1.x branch.

Why not? If we wait for a few more months and releases (we can even check the usage statistics for the pre-1.6 releases), this should affect almost no one. And even for those, it would only cause log messages about the missing module.

I don't really plan on creating a 2.x branch, I planned on just removing deprecated stuff either over time or with Drupal 9. Module can't use semver anyways, so no use feeling too bound by its rules.

Try re-saving the views, that should remove the dependency on the module.

You could try manually removing the dependency, by exporting, changing and importing the config.

Huh, great idea! Wouldn’t have thought of actually uninstalling a module in its own update hook, but apparently it works fine.
However, I’m a bit worried about the first update hook: just loading and re-saving all views seems pretty time-consuming for larger sites (as we probably all know, some sites have staggering amounts of views, and views aren’t really small objects either), and might even lead to memory exhaustion for some. Checking whether the view in question actually has a dependency on the module should save a lot of time and database writes. But for preventing issues when all views are loaded at once, we might need to convert this to a batch-ed update. (On the other hand, I guess all (enabled) views are already loaded by Views under certain circumstances (e.g., determining all Views pages), so it might actually be fine. Still, not re-saving them if they have nothing to do with us seems like a good idea. No telling what problems we might trigger with that, on the potentially thousands of sites this would run on.)

Or, alternatively, just get rid of the first hook and leave the user dealing with it if there are still dependencies. It might not work in a lot of cases, but then at least everyone would know they need to uninstall the module.

Also, in the second hook, shouldn’t we rather throw an UpdateException if uninstalling fails, so we make it clear that the user has to take some action? I don’t think that would prevent other updates from running, right?

Also, two minor nitpicks (among them that first lines of doc blocks are exempt from the 80 character limit), see attached revision.

This is new to me. I understood this rule as "should be only 80 cols, but can not wrap to another line".

Yes, that’s what I meant. Poorly phrased, sorry. I just meant that a line break was “more forbidden” than an overlong line in this case.

Regarding the patch: Not sure why I didn’t pounce on that earlier, but we can’t actually load or save views in an update hook, according to the documentation:

In particular, loading, saving, or performing any other CRUD operation on an entity is never safe to do (they always involve hooks and services).

So, let’s get rid of the first update function after all, alright?
(We could also remove the dependency from the config object directly, of course – but not sure whether that’s wise.)

Also, it seems you included another issue’s code in your patch.

Alright, thanks!
Postponing until the next release, then we should finally be free to remove this!
Thanks again for the great suggestion, legolasbo!

Alright, release created – let’s do this!

Awesome, thanks for reviewing!
Committed.