Don't mark calls as cancelled if they are successfully completed.

[temawi]

The semantics around cancel vary slightly between ServerCall and CancellableContext - the context should always be cancelled regardless of the outcome of the call while the ServerCall should only be cancelled on a non-OK status.

This fixes a bug where the ServerCall was always marked cancelled regardless of call status.

Fixes #5882

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Terry Wilson (9b2918e, 44607a0, c09379d, 645ae56, 4d984db)

[ejona86]

Let's wait for the API review before merging. When merging, make sure to "squash" the many commits into one (rebase is for when 1 commit or a collection of commits you intend to keep separate).

You'll need to fixup the commit description when squashing. The text you have in the PR title+description is perfect, so just copy them to the commit description. See the example commit description in https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html if you are unfamiliar with the normal formatting. The seven rules from https://chris.beams.io/posts/git-commit/#seven-rules sum things up succinctly.

I tend to squash my commits before sending out the PR (or heavy use of --amend), and have the commit include the description I want to show up in the PR. If you only have one commit when creating a PR, github copies the subject/description from the commit.

We tend to prefix the commit summary with the component being modified, so here we'd prefix it with "core: ". Not a huge deal, but is helpful as it can shorten the title line while providing more context and make it easier to skim.