Allow settings to be enabled/disabled as needed

[brightball]

I integrated sendgrid_postback with an existing application that already had some fairly complex email handling. We're using Mailhopper to store outgoing emails, tacking the uuid, events, and state onto that email table so we can keep everything together, embedding other sendgrid headers (categories) into outgoing emails from a parent class, and also tracking the user_id with the outgoing user for most of their emails too.

When we first pulled in sendgrid_postback it was making a lot of assumptions about things working a particular way so we had to add configuration options that would allow us to turn off and replace parts of it (like the mail interceptor) and replace it with our own as needed.

Additionally, we use Sendgrid as the single delivery point for our entire company's infrastructure, so not all of the emails received by postback will be sent by the app (and therefore, will not have a uuid) so we modified the receiver to handle emails without a UUID differently (which we track in the sendgrid_reports table that we built to store reports from the sendgrid_toolkit gem).

Let me know what you think of the changes.

[brightball]

Oh, also, we toggled the SSL requirement for 2 reasons.

1. Simplified local testing.
2. If data has been posted without using SSL, it's already been put at risk. There isn't a security benefit to ignoring the request once the information has already been sent over the wire unencrypted so we just opted to trust the postback URL in our sendgrid settings.

[DougPuchalski]

Hi there, glad you've found this useful and thanks for contributing. Here are my initial thoughts:

• If possible I like to see some of the commits rebased so that things aren't done then redone, unless it gets overly complex. i.e. changing from enable/disable, if/unless, etc. Nicer to see a clean commit log with only the final changes. The ideal would be a single commit per feature unless there's a value in the history of each commit.
• Let's add a changelog summarizing your enhancements.
• Version bump should probably not be in the pull request. I will then annotate your changelog entries with a new version number and bump here.
• I'm wondering about the name "generic" event receiver. What do you think about calling it a "secondary"?