Switch to Railtie, add config.paper_trail.enabled

[Hermanverschooten]

This PR does 2 things.

• It switches to using a railtie to include paper_trail, fixing the deprecation warning with Rails 4.2.5,closes Can't remove deprecation warning after updating to 4.0.0 #584
• It allows you to disable of paper_trail from the environment configuration, closes PaperTrail always enabled in controllers. #635

[jaredbeck]

This PR does 2 things.

Would it be awkward to separate this into two PRs? Thanks.

[batter]

Also, the Railtie class should be housed within lib/paper_trail/frameworks/rails

[batter]

And it should be loaded in by the PaperTrail::Rails module most likely

[Hermanverschooten]

I am not familiar with the codebase, I just replaced it in the spot where active record was loaded before.
But I'll have a got at it.

[Hermanverschooten]

Ok, I moved the code to their respective frameworks.
About splitting the PR, I don't know where/how to access the config variables outside of the RailTie.
So the second PR would still be dependent on this one.

[jaredbeck]

This method, and the @disabled ivar, seem unnecessary, given that we already have enabled=.

[jaredbeck]

There is another problem with the proposed @disabled ivar, that I didn't see before. PaperTrail::Config is a singleton, so its instance variables are not thread-safe. That's why we started using RequestStore.

As I stated in #635, we have already decided that the flag which enables PT should be thread-safe. It would be very confusing to have two flags controlling whether PT were enabled, and even more confusing if one is thread-safe and the other (@disabled) is not.

I'm going to continue exploring this PR, because I want to learn more about railties in hopes that will fix #635. As it stands, we can't merge this, but let me see what I can come up with.

[jaredbeck]

Unfortunately, simply removing the non-thread-safe @disabled ivar and keeping the rest of the changes re: railties fails to fix #635. Herman, do you have any other ideas?

[jaredbeck]

In #635, we are discussing making the main flag "global" again (ie. moving it out of the RequestStore)

[jaredbeck]

Closing because this PR is continued by #717, which keeps @Hermanverschooten's idea and authorship (thank you!) but renames certain methods to clarify which are thread-safe and which are not.