Inline trivial API-wrapper actions

[gnprice]

This carries out a small cleanup I described at #4899 (review) (/cc @AkashDhiman):

1 more thing I did on my own in this revision is that I am using api.setSubscriptionProperty instead of dispatch(setSubscriptionProperty) used previously.
is there any difference among them?

Good question. As you can see in the implementation of the setSubscriptionProperty thunk action, it's a pretty trivial wrapper around api.setSubscriptionProperty -- it's not really adding any new behavior.

I think the answer is that that wrapper (and the similar trivial thunk-action wrappers we have for some other API calls) shouldn't exist, and we should just use the api.foo methods directly, just as you do in this revision.

That's because I don't think there's any meaningful semantics being added by those wrappers. That is, not only do they not add any significant behavior or logic, but there also isn't any way their semantics meaningfully differs from the underlying api.foo methods -- it's not like there's something they're abstracting away, that just happens to have a trivial implementation but where the fact the implementation is trivial is itself a nonobvious fact. (For some examples of functions with trivial implementations that do nevertheless have nontrivial semantics, see src/recipient.js -- particularly streamNameOfStreamMessage or pmTypingKeyFromPmKeyIds.) So they don't gain us anything.

And conversely, the extra wrapper has a real cost -- an extra layer of indirection to jump through when you're reading the code and working out what it does.

[chrisbobbe]

Thanks, LGTM! Merged.