Add old signature back as constructor overload for `TwilioRestClient`

[Swimburger]

A while ago, a new optional parameter was introduced to the constructor of the TwilioRestClient which seems to be a breaking change. If you depend directly on the Twilio package, update to the latest version, and recompile, this wouldn't be a change. However, if you update the Twilio package without recompiling the project or dependency that is using it, it will not find the constructor with the signature it was originally compiled with, which throws this exception:

Method not found: 'Void Twilio.Clients.TwilioRestClient..ctor(System.String, System.String, System.String, System.String, Twilio.Http.HttpClient)'

A customer ran into this and asked a question about it on StackOverflow. They are using the Microsoft.Azure.WebJobs.Extensions.Twilio which hasn't been updated since 1/26/2021 and as a result it depends on the Twilio package version 5.6.3. This version used the following constructor signature for TwilioRestClient:

public TwilioRestClient(
    string username,
    string password,
    string accountSid = null,
    string region = null,
    HttpClient httpClient = null
)

(source code on GitHub)

The customer manually added the Twilio dependency using the latest version (5.75.1). In this version of the package, the following constructor signature for TwilioRestClient is used:

public TwilioRestClient(
    string username,
    string password,
    string accountSid = null,
    string region = null,
    HttpClient httpClient = null,
    string edge = null
)

(source code on GitHub)

There's an extra optional parameter edge. I didn't expect to be a breaking change, but I guess it is a breaking change in this scenario where you're using a package that is compiled to use the old constructor signature.

I do believe that Microsoft recommends overloading methods and constructors instead of adding optional arguments. This may be the reason, but I need to look into this more.

I have already created an issue for the Azure package to update its Twilio package version which should also fix the issue.

However, I also think we should add back the old signature. For future changes, we should also keep this possibility in mind and make sure we don't remove old signatures but overload them with new parameters.

[claudiachua]

Hi @Swimburger, Thanks for bringing that to our attention. This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog.

[Swimburger]

PR added for your convenience: #612

---

Update: The new signature can cause ambiguous constructor signature issues into existing code bases. Since this would be another breaking change, I think we should close this avenue and hope that the Azure Functions library will update their Twilio dependency.