Don't reject m.request Promise if extract callback supplied

[spacejack]

Changes to accommodate #2000.

Description

m.request will no longer reject the Promise if the caller supplies an extract callback.

Motivation and Context

See #2000

How Has This Been Tested?

Test added.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated docs/change-log.md

[spacejack]

Docs should be updated, but just waiting to see what the response is to this change first.

[tivac]

LGTM for mithril@2.0.0

[spacejack]

Updated the docs, plus a minor edit to the "Retrieving response details" section that I think is a little more accurate.

[dead-claudia]

I like this. I actually find it a little surprising that it didn't work that way, since that's pretty much how the docs seemed to explain it.

[dead-claudia]

Should we also add a test to ensure that a throwing extract still errors? Or is it already tested (in which this one needs its name clarified)?

[spacejack]

Ok, I've added an additional test for that. I don't know how to ensure that the catch actually fires (I console logged it while testing to be sure that it did.) But I don't know how to get ospec to fail if line 546 isn't reached. The other tests don't seem to deal with that either, I suppose they assume those code paths will execute.

[dead-claudia]

@spacejack Errors thrown from extract itself should logically become rejections. Anything else is horribly unhelpful at best.