Description of problem:

While we now do support 'lvmetad' and 'lvmpolld' to finish some 'postponed' operation we have their race-window where client may obtain misleading 
info about given LV.

i.e. thinLV has  device_id.

When we 'merge' thinLV1 into thinLV2 - it's a 'dynamic' action marked
in metadata which is cleared later by polling process.
However until this clearing happen - we always show various thin segment parameter for an 'origin' thinLV - while physically there is already
active 'merged' thinLV instead -  so user gets different device_id
for the 'active' device.

Think about the correct and generic solution as this touches all elements displayed for thinLV - so for merged LV it needs to dynamically show
data either for thinLV1 or thinLV2 according to life table state.

Note: the 'race' windows is relatively 'small' but still we can observe it's being occasionally hit by testing machines.


Version-Release number of selected component (if applicable):
2.02.169


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: