fix(recurly): remove conditional fraud instantiation

[moeenatepidemic]

The conditional check before instantiation of the fraud attribute makes the calls to the .configure() idempotent after the first one. For instance, if some user visits the payment form, the first visit will have the fraud_session_id and other fields injected successfully. But if the user decides to take a tour and return to the payment form, the second .configure() will have no effect and no fraud attributes will be available.

Here we have two forms as an example. The second one, calls the .configure() after a few seconds which has no effect on creating the fraud attributes.

With the fix in this PR, the fraud object instantiates with every .configure() call and the attributes are available in the second form.

Currently, we put delete window.recurly.fraud before the call to .configure() in our code to mitigate the problem but we thought it was better to create this PR.

[coveralls]

Coverage remained the same at 92.599% when pulling 853cbb7 on moeenatepidemic:fix-fraud-configuration into 1f42812 on recurly:master.

[chrissrogers]

Hi @moeenatepidemic thanks for submitting this. I think we'll need to make some changes to prevent this from creating a breaking change, which in this library we strictly can't allow.

I think we have a couple of options:

1. Create a FraudDataCollectorElement, which can be instantiated within an Elements group. This will allow tokenization of the Elements to proceed with distinct fraud data collection per group.
2. Expose the Fraud class for public use to facilitate multiple instantiation. The Fraud class would likely need to be given a signature variance pattern in its factory for internal vs external use patterns, and I'd also suggest making the fraud session id readily readable, so that it can be re-used like you're looking to do.

I'd like as well to learn some more about your use-case here if you're able to provide it. That can help determine the nature of the change to support it.