scaling policy alarm_url invocation is blocked instead of async

[JunJie Nan]

The invocation of scaling policy alarm_url is in a blocked way, so if the scaling operation is time consuming the api timeout issue may be found.

Steps to reproduce the problem:
1. heat template using
     https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml
2. heat stack-create -f asg_of_servers.yaml asg ...
3. heat output-show asg scale_up_url
4. curl -i -X POST "THE_SCALE_UP_URL"

Expected result:
it should be accepted and execute async
Actual result:
It waits until everything done

[Steven Hardy (shardy)]

Yeah, this is actually a problem for all signals AFAIK

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/144863

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/144863
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=37ef66970510972af54ce6835ec234f3e30a0a88
Submitter: Jenkins
Branch: master

commit 37ef66970510972af54ce6835ec234f3e30a0a88
Author: tengqm <email address hidden>
Date: Sun Jan 4 16:02:32 2015 +0800

    Enable resource signals be handled asynchronously

    This is an attempt to fix bug #1394095 which reported that alarm_url can
    be signaled only in a blocked way. The reason is that the resource_signal
    API was a synchronous call. To avoid breakng CFN/OpenStack WaitCondition
    behavior, a new 'sync_call' argument is added which default to False.

    A not-so-related fix to test_engine_service.py (L2161-2163) was included
    in this patch because without that fix, I was not able to pass the test
    cases. It was so trivial, so I don't think it deserves a separate patch.

    Closes-Bug: 1394095
    Change-Id: I45e094630ef01b34d09248dbac17ac477933ef53