core: replacing fenceSpmStorage with logic within engine

Currently when the SPM is in different statuses the user can manually
confirm that the host has been rebooted in order to attempt to start the
spm on a different host.

That confirmation propogates to the execution of FenceVdsManuallyCommand
that may execute the fenceSpmStorage verb on vdsm through some host.

The fenceSpmStorage verb edits the pool metadata to indicate that
currently there's no host which is the SPM. Later on when the engine
will enter the start spm flow, it will execute the getSpmStatus which
should return that there's no spm and then the engine will attempt to
start the spm on some host within the data center.

On storage pools that use the StoragePoolDiskBackend this flow works, but
when using the new MemoryBackend the spm status result is being returned
from the cluster lock, the data there isn't editable at the moment so on
that case, the spm won't be able to start on other host (as the returned
result would indicate that there's a spm).

On this patch when a user confirm that the spm has been rebooted, we'll
save that in the memory, when the spm selection process will attempt to
select a new spm in case that the reported spm was confirmed to be
fenced by the user - we'll proceed with starting the spm on another
host.

Change-Id: I2e489cd4ff1f8e8686c89d8ceab72c3af3653a56
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1092752
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: removing fenceSpmStorage verb and related classes

The use of fenceSpmStorage was removed in the previous patch in the
series, as it's not used anymore it can be safely remove along the
related classes.

Change-Id: I593a0620696729500d740c632a2a149c09366cbc
Signed-off-by: Liron Aravot <laravot@redhat.com>