Bugfix for Hash/Secret lock transactions with Delegated Harvesters (task#5pm2hb)

[ruellm]

… Added version in LockInfo entry and notifications. Upgraded version of Hashlock and secret lock to support version 2

change notes:

1. I did not create a different version (no version 2) of notification for HashLockNotification and SecretLockNotification, but instead I added a new member "Version" in the base class BaseLockNotification, I thought it is simpler this way, since notification is just handled within the chain and will not matter for old blocks.
   Also adding new version of notification means adding new observer for notification which only differs in setting the version of the cache entry, it will be a redundant observer because both old and new observer will have to set version anyway.

Also, Version information is already stored in cache anyway, we just need a variable in the chain that handles it.

2. The new attribute "Version" added in lockInfo entry is only changed for LockInfoSerializer version 1, the version 2 of serialzer which is use for Operation plugin was not modified. however Version attribute of lockinfo defaults to 1 for all.

[alvin-reyes]

Task linked: CU-5pm2hb BUG: Hash/Secret lock transactions with Delegated Harvesters

[xgreenx]

Let's support only version 2=)

[ruellm]

I made changes b3267d5

[xgreenx]

I agree with you that this solution is more beauty, but I'm not sure that we need to do changes related to transaction's version by different way.

I think will be better do it by ugly way with the same handlers but for another version of notification.
Because this variant allow us to have the same steps when we are doing any change like this(like tempalte how to do changes related to versioning=) ).

But if @otsybizov agree with beauty variant, then I agree too=)

[otsybizov]

I agree with adding version field to notification structure. But I don't agree with the changes in the lock info serializer. You could use the 2nd version of the serializer rather than changing the 1st version. Having 2 different serializers for the lock entry version 2 is error-prone solution, potentially someone can use invalid serializer and damage the cache.

[ruellm]

@otsybizov thank you for your feedback, I have a question.
just to confirm your suggestion, instead of changing verison 1 of LockInfo serialzer, we will use the second version instead defined here ?

cpp-xpx-chain/plugins/txes/lock_shared/src/state/LockInfoSerializer.h

Line 73 in c5a1b82

struct LockInfoSerializer<TLockInfo, TLockInfoSerializer, 2> {

does this mean I will change hashlock info serialzer to use this as well? change this line

cpp-xpx-chain/plugins/txes/lock_hash/src/state/HashLockInfoSerializer.h

Line 37 in c5a1b82

struct HashLockInfoSerializer : public LockInfoSerializer<HashLockInfo, HashLockInfoExtendedDataSerializer, 1> {};

how will the first version entry be handled?

[otsybizov]

Now, as we have two versions of hash/secret lock info, this becomes more complicated. In both plugins you need to first read the version and then call appropriate serializer when loading entries from cache. And similarly, depending on the entry version, call appropriate serializer when saving data to cache. I'd suggest to add a new LockInfoSerializer template scecialization (version 3) that does that.

[ruellm]

changes pushed here b3267d5