Mailer queue

[difernandez]

Changes

For mails to work with sidekiq, a mailers queue must be defined. This PR adds that queue to sidekiq.yml when running create or install. This was done by adding in bg_processor a new public method, add_mailer_queue. This is used in add_sidekiq and in the mailer recipe when sidekiq is already installed at the moment of running the mailer install.

Other things in this PR:

• Moves add_sidekiq away from private, as it wasn't accesible from mailer recipe
• In bg_processor recipe, checks for None value in mailer recipe. This is the default test value, and as it was before it was wrongfully enabling the first recipe for all tests
• In schedule recipe, appends schedule section to .yml, in order to not remove mailers queue (and any additional content it may have)
• Disables RSpec/BeforeAfterAll for potassium itself

Alternative approach

I'm not sure the way I did it is the best way, it feels like mailer and bg_processor recipes are too dependent of each other. I think there's another way of going about this that keeps the responsibility of adding the mailer queue in the mailer recipe, but again, not sure if it's better:

• Define add_mailers_queue in mailer recipe
• Wrap add_sidekiq in a run_action(:install_sidekiq) block
• In mailer recipe, something like this:

  if background_processor_recipe.installed?
  add_mailer_queue
  else
  if !background_processor_answer
  background_processor_recipe.add_sidekiq
  end
  after(:install_sidekiq) { add_mailer_queue }
  end

I haven't seen run_action used in recipes much. Would appreciate opinions on this.

Edit: I added a new commit with a refactor that uses this approach. It was mainly moving stuff around, I had to make some methods public, because inside the run_action and after you are not in the context of the recipe, so I had to access thos methods from "outside" using recipe.some_public_method. Let me know what you think

Closes #334