Fixed some problems in group code found during review

[ethouris]

Things found during the review:

1. Synchronization group data with the socket data at the caller side:

• wrong reaction on isn == 0 (0 is a perfectly legal sequence value), which likely was remaining after the fact that a freshly created group has recorded scheduling sequence undefined
• the right "undefined sequence" value is -1, but this no longer makes sense because the group is now always initialized the schedule sequence number due to another bugfix
• the intention was to synchronize the latency value for the group from the value taken from the first socket in case when the group didn't get this information yet. The condition to do it was then changed to simply checking if the group is empty. Also the synchronization done at the caller side has been changed to not perform the sequence number derivation, as it doesn't make sense here - now the ISN is created in the group and it's the socket deriving this value from group, not the other way around

2. The use of getMasterData has proven to be now informative only - therefore the whole call is put under ENABLE_HEAVY_LOGGING condition for clarity.

3. Comparison of the expected peer id in case when the group is not empty should result in rejection. This is a probable situation if the user has mistakenly made two connections within a group, but these endpoints do not designate the same application at the peer side. In this case the returned peer group ID will be different for the second member socket, and this means that the address of the second connection is wrong, stating that the first was right.

[maxsharabayko]

Is it valid now?

[ethouris]

Yes. This explains why this call is here.