RefPort's sometimes handled a time step late

[PhilippPlank]

Objective of issue: Deterministic behavior of when data sent via a RefPort is received by the target process. Occasionally it was possible that the receiving process moved to the next phase before all of its VarPorts got serviced, because sending data via a RefPort does not block. Introducing of a wait() method for RefPorts makes sure that sent data is serviced before the process finishes (which blocks advancing a time step and ensures all VarPorts on the receiving process will be serviced beforehand).

Lava version:

• 0.3.0 (feature release)
• 0.2.1 (bug fixes)
• 0.2.0 (current version)
• 0.1.2

I'm submitting a ...

• bug report
• feature request
• documentation request

Current behavior:

• Occasionally it was possible that the receiving process moved to the next phase before all of its VarPorts got serviced, because sending data via a RefPort does not block.

Expected behavior:

• Introducing of a wait() method for RefPorts makes sure that sent data is serviced before the process finishes (which blocks advancing a time step and ensures all VarPorts on the receiving process will be serviced beforehand).

Steps to reproduce:

• Run the PilotNet example using Reset process. It occurs when running around 100 samples (~1600 time steps)

Related code:

insert short code snippets here

Other information:

insert the output from lava debug here