tree eb98fb001d129f6e03a5aab2aeb5546882c06d54
parent 7d7e00146d89a28b7205ba2ef2a942b8a9208d78
author Lei YU <yulei.sh@bytedance.com> 1669182593 +0800
committer Lei YU <yulei.sh@bytedance.com> 1689938882 +0800

Correct the timing of emit_object_added

The deletion of the dump objects emits InterfacesRemoved signal, but the
interfaces removed in the signal does not contain the interfaces defined
in the base class phosphor::dump::Entry:
```
xyz.openbmc_project.Common.OriginatedBy
xyz.openbmc_project.Common.Progress
xyz.openbmc_project.Dump.Entry
xyz.openbmc_project.Object.Delete
xyz.openbmc_project.Time.EpochTime
```

This results in the mapper still keeping the objects even if the object
is removed from DBus, and it becomes inconsistent between the DBus
objects and mapper.

Adjust the inheritance sequence, so that in destruction,
emit_object_removed() is called when all the interfaces are there, so
that all the interfaces could be included in the signal.

Without this change, the destructor sequence is (Taking BMCEntry as
example):
1. phosphor::dump::Entry is destructed, no signal is emitted;
2. phosphor::dump::bmc::EntryIfaces is destructed, signal is emitted,
but at this time, only the interfaces implemented by
phosphor::dump::bmc::EntryIfaces is included, which is the root cause of
the problem.

With the change, the destructor sequence is:
1. phosphor::dump::bmc::EntryIfaces is destructed, signal is emitted,
and all the interfaces are included in the signal;
2. phosphor::dump::Entry is destructed, no signal is emitted.

So all the interfaces implemented by BMCEntry is included in the
InterfacesRemoved signal, and thus the issue is fixed.

Tested: Before this change:
        1. Create a dump, say /xyz/openbmc_project/dump/bmc/entry/2
        2. Delete it
        3. Mapper still list the above object although it does not
        really exist.
        With this fix, verify the above issue is fixed.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I76710fa9b8d23344cf979bd8f3bdcc331e663264