$httpBackend should report stack trace of unexpected requests

[ttencate]

When $httpBackend says Unexpected request: GET ..., the printed stack trace points to the $httpBackend.flush() call, not to the place where the actual request was triggered from. This makes such errors hard to debug, especially if the request is made in a place with many callers.

We could record the stack trace when any of the request methods on $httpRequest are called, and show that stack trace in addition to the Unexpected request: ... message.

Related but different: #10596

[ttencate]

If people think this would be a good approach, I can write a PR.

[zakhenry]

👍 this would be a very handy addition

[ttencate]

This is not as trivial as I thought, because $http (which remains untouched by ngMock) only calls $httpBackend asynchronously when this promise's resolve function is processed. Of course by then we're somewhere in a digest loop, so the mock $httpBackend is no longer able to see the original stack trace.

One ugly hack I can think of is to have ngMock register a decorator on $http, which adds a fake X-Stack-Trace header field to the request. (It needs to be a header because the config object itself isn't passed on to $httpBackend, but headers are.)

But even that is hard, because $http is used as a function. The original $http.get method and friends all call the $http function from their closure, not from their this pointer, so we cannot just create a wrapper around $decorator and copy these methods onto it -- they would end up calling the original $http and not the wrapper. We could wrap each of these methods individually, but that'd just be piling hacks upon hacks.

As an alternative, I would really like to make the initial call to $httpBackend synchronous, which is a two-line change. But since it would also trigger request transformations and such, I'm concerned that that would break too much existing code in subtle ways...