Changed phone number normalization to use more robust method.

[shaunpersad]

• We're now using this method: https://www.npmjs.com/package/libphonenumber-js#parsephonenumberfromstringstring-defaultcountry

• It also checks if the phone number is possible, which will not allow numbers that are too long or too short.

• One thing to note, is that for requests that don't have a location associated with it, non-internationally formatted numbers will fail. For example, 516-555-5766 is a valid US number, but it's impossible for the library to format this into the international format that Twilio expects ( which prefixes +{country code} to the number), since it could also be a valid number in another country. Therefore having a location is imperative for best results.

• I also temporarily fixed the failing tests that depended on request handlers being promise-based.

[shaunpersad]

Pivotal task link: https://www.pivotaltracker.com/n/projects/2207263/stories/164435171

[prashanthsadasivan]

Thanks for fixing that test failure. LGTM.

Do you know off the top of your head which requests don't have a location? otherwise we can take a look thru the db. my guess is probably routes? not sure though.

[shaunpersad]

This comment has a query that shows some instances where there is no location: https://www.pivotaltracker.com/story/show/162386185/comments/200212105