There are several changes to this module:

1. The use of an explicit stack in Participable#participants
2. Proc behaviour has been changed
3. Batch permissions checking

== Explicit Stack

Participable#participants no longer uses recursion to process "self" and
all child objects, instead it uses an Array and processes objects in
breadth-first order. This allows us to for example create a single
Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
a ReferenceExtractor removes the need for running potentially many SQL
queries every time a Proc is called on a new object.

== Proc Behaviour Changed

Previously a Proc in Participable was expected to return an Array of
User instances. This has been changed and instead it's now expected that
a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
value of the Proc is ignored.

== Permissions Checking

The method Participable#participants uses
Ability.users_that_can_read_project to check if the returned users have
access to the project of "self" _without_ running multiple SQL queries
for every user.

This method used to call strip! on input strings which will mess with
the strings if they're re-used or frozen.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Conflicts:
	spec/features/issues_spec.rb
	spec/models/forked_project_link_spec.rb
	spec/models/hooks/service_hook_spec.rb
	spec/models/hooks/web_hook_spec.rb
	spec/models/project_services/hipchat_service_spec.rb
	spec/requests/api/project_members_spec.rb
	spec/requests/api/projects_spec.rb
	spec/requests/api/system_hooks_spec.rb
	spec/services/archive_repository_service_spec.rb
	spec/support/matchers.rb
	spec/tasks/gitlab/backup_rake_spec.rb

These fixes were performed automatically by Rubocop's `-a` flag.

We only want them shortened by the filter, which calls to_s