Graceful shutdown controlling process.

[terencefan]

Split from #689

Contain only ControllingProcess for graceful shutdown, a few new Constants and 2 new Options

UPDATE 11/1

@vicancy @KKhurin @vwxyzh

After discussed with @chenkennt, we found a barrier between all client connection closed and close server connections is necessary.

Considering if our SDK connected with multiple Endpoints, and it would like to broadcast to all Endpoints after receiving a message. In my current workflow, I shutdown the Endpoints respectively, which means if all client connections from Endpoint A have been dropped, the relevant server connection will be dropped immediately. And if our SDK received a message from Endpoint B, it wouldn't have any chance to broadcast messages to Endpoint A.

So maybe I have to introduce a barrier to handle this situation, and the workflow may like this:

By doing this, we can make sure our server connections to each endpoint will stay alive until even our SDK has received the last message from its last client connection.

Is this useful? Please give me your advice.

And here is the overall process:

The CloseAsync method will be implemented in the main PR.

[vwxyzh]

In my opinions:

• ShutdownAsync should be StopAsync.
• Merge with fix auto reconnect after stop bug #707

[terencefan]

@vwxyzh
There are still small differences between these 2 methods,
For StopAsync, we cancel the pending messages in the pipe.
For CloseAsync, we simply send a message to our runtime, but nothing to do with our pipes.

In another word. StopAsync close server connection positively on the SDK side, while CloseAsync just tells our ASRS and wait for the connection to be closed passively.

[vicancy]

Delay 1 sec is too long, maybe 10 milliseconds?

[terencefan]

Actually we don't have to wait in the current implementation since our StartCoreAsync doesn't truly await anything before calling inner StartAsync.

But what if it does something that needs to be awaited, and, won't cost too long in future implementation? (like write a log to file, cause real await but very short)

That's why I introduced a 1s delay in this test case. 1s for 1 test case is fair, to strike a balance between robust and time-costs.