mdb implementation inefficient

[KanjiMonster]

When mdb support was added, it was partially based on the misbehavior of the cache callback v2 for updated objects recently fixed.

Before the fix, the new argument contained the changes, but not the full database, so any users just needed to handle the entries in new.

But with the fix, they now need to calculate the diff between the two databases, which is not very efficient.

Additionally, since we have exactly one object per bridge that contains all multicast subscriptions, any update notification require a clone of the full database, and since there is only one object, you also cannot search for anything meaningful (e.g. if you want to get all multicast subscriptions on a certain port, you will need to get the database object, then iterate over all entries and find them yourself).

AFAICT think to make this more usable, we would need to change its design, but that is not possible in a non API breaking way. At the same time, I'm not sure we could have two different implementations for the same netlink messages.

So yeah, my first idea would be to split up the database and make each {port,vlanid} an object, similar to how fdb has neighbors and not a single fdb object per bridge.

This would fix the inefficiency, and makes it possible to search the cache. But it would be a different API.

There is also the second complication that the mdb contains two types of objects; mdb entries/subscriptions and multicast routers, which have completely separate attributes.

Not quite sure how to bring them into one cache. Or can one parser update two caches? Maybe it needs to work to similar how different link types are handled.