engine: Improving memory footprint during audit logging - easy one

The following variable allocation is unneeded.
Improved memory allocation during every get from DB operation

Change-Id: I21b4964f278d067aa9daa0b153099b20f348919b
Signed-off-by: Michael Kublin <mkublin@redhat.com>
engine: Simplify AuditLogHelper

Replacing hand made code by java standard code.

Change-Id: Ibf52160dba842985b6cb1fa66fc08c538b2ead6a
Signed-off-by: Michael Kublin <mkublin@redhat.com>
engine: Improving memory footprint for almost every command in the system

The custom properties is private case, so allocation of HashMap is required only
in small number of commands, benefit - we will not allocate thouthands of HashMaps
In case that we need a custom properties , map will be allocated

Change-Id: I266ac0abd5e53ec7c7948059ee575aac6b53c17b
Signed-off-by: Michael Kublin <mkublin@redhat.com>
engine: Clean unused method

The following method is not in use, so removed

Change-Id: I82d7ae999a38c4ec9690192e4e26d09bf0f5343f
Signed-off-by: Michael Kublin <mkublin@redhat.com>
engine: Super audit log improvement

So what is current (before patch) behaviour inorder to make some audit log
message:

1. Pass class that extends AuditLogableBase
2. Pass a message with keys that should be replaces based on properties from passed class
3. Go over all properties in passed class, collect them and create a HashMap with key as
   property name and value as property value
4. Replace keys in message using a created HashMap.

Now, lets take a look on 3, how we retrieve a properties - we invoke all getXXX methods in our class.
How many getXXX methods has simple AuditLogableBase class?
How big will be our HashMap?
How many queries/calculations will run during invoking some of the getXXX messages, because our class not
simple bean?
The only answer is a lot, only in simple run I saw a HashMap with 150 values (sic!).

I fix this, if I have a message I know all keys that I need, I don't need to go throught all getXXX methods.

Intresting fact: optimized solution required less code.
Another intresting fact - adding of additional getter to AuditLogableBase, before a fix, was like adding a small
brake to the system.

Change-Id: Id68a098be36fcfc47c23c57fce3abea50e6273e3
Signed-off-by: Michael Kublin <mkublin@redhat.com>
engine: Additional clean up in AuditLogDirector

Variable auditLogable can not be null, if it null we will fail on
NullPointerException inside updateTimeoutLogableObject method.
After removing such condition, were removed all relevant and dead code.
Also, I chnaged tempVar to auditLog varibale, don't see reason for using tempVar

Change-Id: Ia0eb406d78965bb0d84c7ce80761028877ab2879
Signed-off-by: Michael Kublin <mkublin@redhat.com>