Implemented RemotingTerminator

[Aaronontheweb]

Third try's a charm. See #774

[rogeralsing]

This is racy.
The RemoteSystemDaemon is not an actor, just an impl of IActorRef (VirtualPathContainer).
So there is no concurrency constraints applied here.

(I could be misreading something ofc)

[rogeralsing]

I checked the scala version and they do not do this, they handle all sender related stuff inside their huge ! tell handler.
IMO, remove the property and add sender to the OnReceive method as it is not an override and we can change the signature as we like, OR
We move all of it into the TellInternal method, which represents the same as the scala !

[Aaronontheweb]

I'm fine with option 2 - I need this data either way.

[Aaronontheweb]

Working on this alongside some other internals fixes for Akka.Remote.

[Aaronontheweb]

Made some more changes to the RemotingTerminator and also fixed a bug inside Helios (threw an exception upon shutdown.)

Looks like I'm locking up one of the Akka.Remote.TestKit.Tests with that Helios change now, so I'll start digging some more into that.

[Aaronontheweb]

Waiting on the latest build to finish, but otherwise this PR is ready to review.

[rogeralsing]

what is the x => x thing doing?
Seems odd too compare each element to itself (?)
[edit] nvm.
clever way of and'ing a list of bools..

[Aaronontheweb]

Yeah, basically I just need to make sure that N endpoints and N transports all shut down successfully and the aggregate bool value should be either "all succeeded" or "not all succeeded"

[rogeralsing]

Question:
The code base (not just here in the PR) is sprinkled with ExecuteSynchronously in a lot of our PipeTo scenarios, and some of those also have AttachedToParent.
Are we doing this consistently? are there good reasons for when we use and not use AttachedToParent
And are they really proven to have an effect together? it seems strange if ExecuteSynchronously wouldn't do this by itself as it must continue directly on the same thread.

[Aaronontheweb]

https://msdn.microsoft.com/en-us/library/system.threading.tasks.taskcontinuationoptions.aspx

Using ExecuteSynchronously supersedes AttachedToParent as far as I can tell, so I've been removing AttachedToParent in a bunch of areas. ExecuteSynchronously is an optimization that's appropriate for the areas where we use it, where the continuation does something simple like formats a message or handles an exception. It's not appropriate for anything that has I/O or is otherwise CPU-intensive. It basically inlines the execution of the next Task.

Part of the reason why I haven't removed AttachedToParent EVERYWHERE is that despite what the documentation says, it's a flag that is applied somewhat non-deterministically it seems, so I'm not sure what the impact of removing it everywhere will be. Call me "paranoid" :p

[Aaronontheweb]

Fixed up the bitmasking on the TaskContinuationOptions