unmapped layer surfaces can contribute to the exclusive zone

[alex-huff]

I believe unmapped layer surfaces should not be considered during arranging. Currently, if an unmapped layer surface is configured with an exclusive zone it can affect the placement of other layer surfaces and will reduce the area returned by non_exclusive_zone().

This can be reproduced in anvil with kitty:

1. run kitten panel --config=NONE --listen-on=unix:@panel-socket --override=allow_remote_control=socket-only --edge=top This creates a single line terminal layer surface anchored to LEFT|RIGHT|TOP.

2. run kitten @ --to=unix:@panel-socket --use-password=never resize-os-window --action=toggle-visibility This unmaps the layer surface. At this point smithay resets the layer surface state to the default (no exclusive zone, 0 width, 0 height etc.).

3. run kitten @ --to=unix:@panel-socket --use-password=never resize-os-window --action=os-panel edge=top This re-configures the layer surface state to what it was after step 1 but doesn't remap it.

4. run kitten panel --config=NONE --edge=top This creates another single line terminal layer surface anchored to LEFT|RIGHT|TOP.

Notice that the newly created layer surface is shifted down to make room for the unmapped layer surface. This behavior isn't present in the other compositors I tested.

[YaLTeR]

I realized this too, on the other hand I can see the intention—when a new layer surface appears, to reconfigure all existing ones right away to make space for the new one (assuming it's about to map). And to make sure computing the new surface size considers the whole new configuration.

I think this would need some refactor to LayerMap to be able to fix this well (I was planning to do some refactoring there, but haven't got to it yet).