Standby service of locations fails when applied repeatedly

[pLeminoq]

In the hope of finding information on issue #73 I repeatedly changed the standby state of the home location in my system. This did not help find anything regarding the memory leak bug revealed two other things:

• Waiting for the result of the setStandbyState method returns before the state has actually been applied
• After a while the standby state could not be changed anymore and resulted in the following exception:

  12:17:27.150 [pool-2-thread-7] ERROR java.lang.Class ═╦═⚀ Fatal implementation error in or by using [wait:10000]!
  12:17:27.152 [pool-2-thread-7] ERROR java.lang.Class  ╚════⚀ WriteLock of LocationData was locked for more than 10 sec by Consumer[LocationControllerImpl[LOCATION[Home]]]!
  12:17:27.154 [pool-2-thread-7] ERROR java.lang.Class =====================================
  12:17:27.155 [pool-2-thread-7] ERROR o.o.j.e.p.BuilderSyncSetup ═╦═⚀ Fatal implementation error in or by using [wait:10000]!
  12:17:27.157 [pool-2-thread-7] ERROR o.o.j.e.p.BuilderSyncSetup  ╚════⚀ WriteLock of LocationData was locked for more than 10 sec by Consumer[LocationControllerImpl[LOCATION[Home]]]!
  12:17:27.158 [pool-2-thread-7] ERROR o.o.j.e.p.BuilderSyncSetup =====================================
  12:17:27.160 [pool-2-thread-7] WARN  o.o.j.s.Timeout ═╦═⚀ Error during timeout handling!
  12:17:27.162 [pool-2-thread-7] WARN  o.o.j.s.Timeout  ╚════⚀ IllegalMonitorStateExceptio
  

After finding out that the method returns to soon I changed the test to switch the standby state every minute. After running for a while the exception mentioned above occurred again so the state could not be switched anymore. This also did not result in an out of memory error.

[pLeminoq]

The exception was likely caused by a timeout when restoring a snapshot. A reason why this could have happened is that the transaction id of a unit has been split by service type and service updates can overwrite each other. E.g. an update for a color state overwrites the current brightness value removing the available transaction id. Therefore the UnitSynchronizationFuture would not return resulting in a timeout. This should be fixed by commit f0e3e5752ccfb4073e01e8692b0fb44155513993.

The second issue that the method returns too soon has also been improved but I think it can only be guaranteed by fixing issue #89

[DivineThreepwood]

Issue is outdated and causing issues are fixed.