Remove cancellation token from CloseAsync APIs

[divega]

This is my conclusion on the conversation started on dotnet/standard#1283 (comment).

All in all, it seems that we are using CloseAsync for cleanup (e.g. in finally blocks) and it is hard to figure why passing the same cancellation token that you are passing to everything else is the wrong thing to do. Hence it is a pit of failure to have CancellationToken in the API.

This should needs to be removed from the System.Data.Common types, but the removal should propagate to EF Core APIs as well.

• In MigrationCommandExecutor.ExecuteNonQueryAsync, we are using DbConnection.CloseAsync(CancellationToken) as part of finally block, and we are effectively passing the same CancellationToken we passed before to DbCommand.ExecuteNonQueryAsync.

• In RelationalTransaction.ClearTransactionAsync we call CloseAsync(CancellationToken) on the connection, also passing the same cancellation token we pass to the previous call that does some work.

• In BatchExecutor.ExecuteAsync same problem.

• In all the execute methods in RelationalCommand same problem.

• In SqlServerDatabaseCreator.ExistsAsync we call IRelationalConnection.CloseAsync without passing the cancellation token! I am not sure if we should call it an oversight 😄

[roji]

PR for token removal in corefx: dotnet/corefx#39070