Allow whodunnit to be a proc

[rangerscience]

Basically, I've got a circumstance where I'm trying to figure out what is changing one of my models (it's not Sidekiq jobs, and it's not going through the controllers...).

Right now I've got:

class PapertrailSidekiqMiddleware
  def call(worker_class, job, queue)
    if(worker_class.class == Sidekiq::Extensions::DelayedClass)
      PaperTrail.whodunnit = YAML.load(job["args"].first).first.to_s
    else
      PaperTrail.whodunnit = worker_class.class.to_s
    end
    yield
  end
end

Sidekiq.configure_server do |config|
  config.server_middleware do |chain|
    chain.add PapertrailSidekiqMiddleware
  end
end

This works, but it also only covers Sidekiq; if there's no place to stick the whodunnit initialization like this, there's no way to make the whodunnit dynamic and record the actual situation.

However, with a change like this, you could set a whodunnit during the creation of the paper trail, so you could evaluate anything you like (inspecting the callstack, the originally run Ruby command, etc etc).

PS - Honestly, I was 100% convinced I wanted this feature as part of tracking down this issue, but in this moment I'm honestly no remembering what the plan was that needed it.... :P

PPS - I totally don't expect this PR to get accepted, but I wanted to start the conversation and figured this'd be more illustrative than making an issue. LMK how I should proceed!

PPPS - I also ran into a couple of issues when first running rspec on Papertrail, so there's a couple of Gemfile commits to fix that.

[jaredbeck]

I think this will not be a commonly used feature, but it adds so little complexity that I'm happy to add it.

Please add an entry to the changelog under "Unreleased"

[jaredbeck]

Please do not edit the Gemfile. Please edit Appraisals instead. But, I don't think any changes to gems are necessary.

[rangerscience]

Kk. I'm not familiar with Appraisals, but I can go figure it out.

[rangerscience]

You're correct, when run via appraisal, everything is fine.

[jaredbeck]

Should the conditional check respond_to?(:call) instead of == Proc?

[rangerscience]

Yah, that makes a lot of sense; sharp knives and all that.

[jaredbeck]

Nice test 👍

[rangerscience]

:D

[rangerscience]

Updated as per review and failed tests; rewrote Git history of this branch to keep it super clean.

I added a bit to the documentation where I (as a new and inexperienced contributor) was confused.

[jaredbeck]

Merged. Thanks for your contribution!