Draft: client: Don't disconnect on receipt of object events destined for zombies

Server side objects give protocol designers exciting ways to break clients. For example, if a client deletes an object at the same time the server is sending an event containing a new object to that object, then we currently silently drop that event. If a following event in the buffer from an object that has not yet been deleted also contains a new object, the wl_map constraint that new objects must be 1 higher than the current highest object count is violated. This results in a disconnect.

Instead, let's augment the zombie accounting code to keep the entire proxy around on deletion, for both client and server generated objects.

This way we can create and immediately delete objects that are destined for zombie proxies - thus creating zombie descendants.

We can go no further to clean this up in the client library - we can't call a destructor because the protocol might dictate that child objects will be automatically destroyed on the destruction of the parent.

So we turn a situation that would lead to an erroneous disconnect into one that may or may not leak object ids depending on protocol definition.

Fixes #74 for some definition of "fix" anyway.

Signed-off-by: Derek Foreman derek.foreman@collabora.com