Ditch backend-agnostic index classes

[ababic]

Well, I think they should become 'base classes' that the backend-specific ones should be based on. This way, they can still be used in type-hints for other backend-agnostic components.

To make it possible to reuse custom index code across multiple backends, backend modules should define their overrides/custom methods in a mixin that can be easily applied to generic index classes to make them work for that backend. Where developers want to register the same index with multiple backends (an unlikely scenario, but hey), they would just define and register multiple subclasses of their generic version, using the relevant backend-specific mixins.

Vector index backends can then easily identify the indexes that apply to them, by checking whether registered indexes use their specific mixin class.

Downsides of this approach would be:

• Devs can't just switch the main vector index backend in settings and expect custom indexes to work... There would be a step to extend from the relevant backend-specific index class too.
• Its joining together two things that are currently separate in terms of architecture. However, in my experience, thinking about the index as a separate/agnostic component has only been a hinderance to understanding what I can and cannot do with it.

[tomusher]

Thanks @ababic, your feedback on this is really useful.

I like this idea, the separation of VectorIndex from backend-specific Index classes has always felt a bit awkward and this seems like a sensible way to rationalise that - it also brings it more in line with Wagtail's search backends which might make it easier for developers to understand.

[tomusher]

I've attempted an implementation of this change over at #65

[ababic]

Resolved by #65