Guards are not evaluated when the event is fired across multiple kernels

[gallandarakhneorg]

To Reproduce
Run this code on two computers:

// First computer
package network

import io.sarl.core.DefaultContextInteractions
import io.sarl.core.Logging

event Ping
event Pong

agent PongAgent {
    uses DefaultContextInteractions, Logging
    on Ping {
    	info("pong")
        emit(new Pong)[ it == occurrence.source ]
    }
}

// second computer
package network

import io.sarl.core.DefaultContextInteractions
import io.sarl.core.Initialize
import io.sarl.core.Logging
import io.sarl.core.Schedules

event Ping
event Pong

agent PingAgent {
    uses DefaultContextInteractions, Logging, Schedules

    on Initialize {
        val task = task("waiting_for_partner")
        task.every(1000) [
            if (defaultSpace.participants.size > 1) {
                emit(new Ping)
                task.cancel
            }
        ]
    }

    on Pong {
        info("ping")
        emit(new Ping)[ it == occurrence.source]
    }
}

Expected behavior
The first agent should display "pong" indefinitely, the second agent should display "ping" indefinitely.

System configuration:
-- SARL version: 0.8.5
-- SARL compiler:

• • Eclipse compiler without Maven
    -- Java JDK version (with the manufacturer name): openjdk version "1.8.0_181"
    -- Operating System:
• • Linux 64bits

Additional context
The computers are connected on a local network with all ports opened, and Hazelcast can connect the SARL frameworks. If the guard [ it == occurrence.source ] is commented, the message is received.

Originally posted by @gbasso in #883 (comment)

[gallandarakhneorg]

This issue is due to the fact that the scoping function is serialized and sent throught the network link. When the scoping function is a lambda, it cannot be deserialized properly into the target host.

We need to re-think the serialization of the scopes when it is used through a network.

Why scope is going throught network link? Because the scope is evaluated when dispatching the event inside the message transport service, i.e. inside the destination host in the case of a network-based communication.

Another issue is: Serialization of the scope breaks the links to the references to local variables inside the agent which emits the event.

Another issue is: Serialization of the scope stores the closure's classname. The corresponding class may be inexistant into the destination host virtual machine.

[gallandarakhneorg]

This problem could be reproduced when using the GsonEventSerializer or the JavaBinaryEventSerializer.

[gallandarakhneorg]

See the PR #888.