raylet memory corruption fixes

[atumanov]

What do these changes do?

There are two memory corruption fixes here:

1. boost::system::error_code message() call returns a corrupted string, even immediately after initializing the error as follows:
   boost::system::error_code error;
   The (temp?) fix is just to replace it with a generic message indicating failure to write message to the socket.
2. an erase is called on an unordered_map iterator, which is then subsequently accessed.
   Iterators to the erased element are invalidated:
   https://stackoverflow.com/questions/38854265/unordered-map-element-being-deleted
   Valgrind was reporting a bad read, which is fixed by this PR.

Related issue number

fixes : #2584
subsumes: #2548

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/7301/
Test PASSed.

[zhijunfu]

It looks strange why error.message() is corrupted. May we could print error.value() as well since that's valid? That might also give some hints on what kind of errors encountered.

[robertnishihara]

Yeah, I think it'd be preferable to do strerror(ec.value()) as in #2548 so that we have the error message, even despite the fact that this is probably not platform independent.

We can address this by factoring out all of the calls to strerror(ec.value()) in a separate function.

[atumanov]

I am not certain that ec.value() is consistent with the errno numbers expected by strerror. There may be another way that's specific to boost. I am looking into it.

[robertnishihara]

@atumanov so are you saying that it is pretty certain that the bug is in boost (as opposed to our code)?

[atumanov]

@robertnishihara , I am not 100% sure, but:

1. without this fix, calls to boost::system::error_code::message() return a corrupted string even when the boost error code object has just been instantiated.
2. valgrind throws an error on access to boost::system::error_code::message()
3. with this fix, valgrind doesn't throw any errors (for the task forwarding unit test in this issue), which means that valgrind doesn't detect any memory corruption issues leading up to the code path where the boost error code is instantiated.

From that, I have some degree of confidence that it's not our code, but not 100% confidence.

I added a utility function to convert boost error codes to ray status objects and cleaned up the code in several places to use this utility function in this PR.

[atumanov]

this PR now subsumes #2548

[pcmoritz]

LGTM, thanks :)

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/7346/
Test PASSed.

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/7355/
Test PASSed.

[AmplabJenkins]

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/7362/
Test FAILed.

[pcmoritz]

jenkins retest this please

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/7370/
Test PASSed.