Fix test_local_embargo_9 about capnp-rpc HOT 2 CLOSED

Example problem (found by AFL and simplified):

There are two vats, Client and Server, each of which starts with a reference to the other's bootstrap service. All calls either return a single capability (x) or Void.

1. Client makes a call, q1, on the server's bootstrap object, getting a promise a=q1.x
2. Client makes another call, q2, on the same target, getting promise b=q2.x.
3. Server asks one question, q3 (c=q3.x)
4. Client responds to q3 with a (the unresolved promised cap from its q1)
5. Server responds to q1 with client_bs (the client's bootstrap service, resolved)
6. Server responds to q2 with c (q3.x, still unresolved)
7. Client makes call m1 on b (sent to q2)
8. Client receives response a=client_bs (no embargo needed)
9. Client receives response b=q3.x, which is a.
   This was q1.x at the time q3 returned, but client_bs now. Which should it use?
   If client_bs, it embargoes the target due to m1.
   If not, b now points at the returned q1, which seems odd.
10. Client makes call m2 on b (which is then held at the embargo).
11. Server receives response that c=q1.x (which is client_bs).
12. Server receives m1 and forwards it to q3.x.
13. Server sends disembargo response back to client.
14. Client receives m1 and forwards it to q1 (the resolution it gave for q3).
15. Client disembargoes b and sends m2 to client_bs.

With b set to the embargoed client_bs in step 9, m2 arrives before m1 (which is now on its way back to the server again). Perhaps a second disembargo is needed?

Alternatively, if b was set to point at q1.x, I think the messages will arrive in the correct order.
But then b ends up pointing to the answered q1, rather than directly at client_bs.

As a third alternative, if messages are sent to their current, more resolved destination (ignoring the spec) then this case works, but can be made to break by sending another message down q3 before m1 arrives at c. Then the server embargoes m1, and m2 arrives first again.

from capnp-rpc.

From https://groups.google.com/forum/#!msg/capnproto/_1kBtRSC51s/GfDTdkLpAgAJ:

Nice example!

It looks like the C++ implementation today will decide b = q1.x, and never allow it to further resolve to client_bs. This "works" but is clearly suboptimal.

For a correct solution, we need to recognize that Disembargo messages can "bounce" multiple times:

The disembargo sent in step 9 has a final destination of client_bs.

In order to get there, it has to bounce back and forth between the client and server twice:

• The client sends it towards q2.x.
• The server, recognizing that it resolved q2.x to q3.x, reflects the embargo towards q3.x.
• The client, recognizing that it resolved q3.x to q1.x, reflects back to the server again.
• The server, recognizing that q1.x resolved to client_bs, finally reflects back to client_bs.

This gives m1 enough time to arrive before the disembargo.

It looks like this is not implemented correctly in C++ currently. It appears the C++ implementation ignores disembargo.messageTarget in the case that the Disembargo has type receiverLoopback. This is incorrect -- it needs to verify that the embargo has reached its final destination, not an intermediate promise. (However, it is "saved" by the suboptimal behavior mentioned above.)

from capnp-rpc.