Refactor cancellation mechanism and make it internal, accessible via experimental nuget.

[Ivanidzo4ka]

Some time ago I added StopExecution method and IsCancelled flag to IHost.

machinelearning/src/Microsoft.ML.Core/Data/IHostEnvironment.cs

Line 98 in fbf282d

void StopExecution();

machinelearning/src/Microsoft.ML.Core/Data/IHostEnvironment.cs

Line 74 in fbf282d

bool IsCancelled { get; }

It was quick solution to make certain algorithms react to stop signal from user. I doubt in long run it's proper way to do it. And it probably required lengthy discussion how to expose stopping functionality (method, or CancellationToken, or something else).

But for now I think it's a good idea to remove method and flag from our public API. Especially considering what no code actually checking IsCancelled flag.

EDIT: We decided to keep this functionality but make it internal and still be accessible via experimental nuget.

[codemzs]

From my experience this kind of work is done via CancellationToken and will be more of a framework design change. You will need to pass that cancellation token from the start till the end or at least through all checkpoints where you would like to stop the execution.

[Ivanidzo4ka]

As I said above, functionality like this deserve proper discussion, and it's not v1 priority.
Let's focus right now on code cleaning.

[codemzs]

@Ivanidzo4ka I wasn't suggesting we do the design work of proper cancellation mechanism now. Anyways PR to clean the cancellation mess is out ...