feature #5453 Cleanup security voters cookbook recipes (WouterJ)

This PR was merged into the 2.3 branch.

Discussion
----------

Cleanup security voters cookbook recipes

| Q | A
| --- | ---
| Doc fix? | yes
| New docs? | no
| Applies to | all
| Fixed tickets | #5084

Blacklisting using voters isn't a good practice and in fact, the article (`cookbook/security/voters`) was almost completely equal to the much newer voter article (`cookbook/security/voters_data_permission`). I've moved the only different piece (access decision strategy) to the newer voter article and then removed the old voter article.

As the old voter article had a much nicer URL than the new one, I then renamed the new article to have the better name and set up a redirection. A [quick search on Google](https://www.google.nl/search?q=%5Blink%3Ahttp%3A%2F%2Fsymfony.com%2Fdoc%2Fcurrent%2Fcookbook%2Fsecurity%2Fvoters.html%5D+-site%3Ahttp%3A%2F%2Fsymfony.com) revealed that there are almost no links to the old article talking about blacklisting specifically, just about voters. So I think we're good here.

The diff is horrible, that's why I've tried to create multiple commits (this will ease reviewing process). The only commit requiring review is 9c169c7 (as the other 2 are just moving and removing stuff).

Commits
-------

93484a7 Remove the old voter article
9c169c7 Rewrite new section
acf66f9 Move access decision strategy section

Author: weaverryan

book/security.rst

@@ -929,10 +929,10 @@ other users. Also, as the admin user, you yourself want to be able to edit
 
 To accomplish this you have 2 options:
 
-* :doc:`Voters </cookbook/security/voters_data_permission>` allow you to
-  use business logic (e.g. the user can edit this post because they were
-  the creator) to determine access. You'll probably want this option - it's
-  flexible enough to solve the above situation.
+* :doc:`Voters </cookbook/security/voters>` allow you to use business logic
+  (e.g. the user can edit this post because they were the creator) to determine
+  access. You'll probably want this option - it's flexible enough to solve the
+  above situation.
 
 * :doc:`ACLs </cookbook/security/acl>` allow you to create a database structure
   where you can assign *any* arbitrary user *any* access (e.g. EDIT, VIEW)
@@ -1281,7 +1281,7 @@ Learn More from the Cookbook
 
 * :doc:`Forcing HTTP/HTTPS </cookbook/security/force_https>`
 * :doc:`Impersonating a User </cookbook/security/impersonating_user>`
-* :doc:`/cookbook/security/voters_data_permission`
+* :doc:`/cookbook/security/voters`
 * :doc:`Access Control Lists (ACLs) </cookbook/security/acl>`
 * :doc:`/cookbook/security/remember_me`
 * :doc:`/cookbook/security/multiple_user_providers`

cookbook/map.rst.inc

@@ -166,7 +166,6 @@
 * :doc:`Security Authorization (Denying Access) </cookbook/security/index>`
 
   * :doc:`/cookbook/security/voters`
-  * :doc:`/cookbook/security/voters_data_permission`
   * :doc:`/cookbook/security/acl`
   * :doc:`/cookbook/security/acl_advanced`
   * :doc:`/cookbook/security/force_https`

cookbook/security/acl.rst

@@ -14,7 +14,7 @@ the ACL system comes in.
     Using ACL's isn't trivial, and for simpler use cases, it may be overkill.
     If your permission logic could be described by just writing some code (e.g.
     to check if a Blog is owned by the current User), then consider using
-    :doc:`voters </cookbook/security/voters_data_permission>`. A voter is passed the object
+    :doc:`voters </cookbook/security/voters>`. A voter is passed the object
     being voted on, which you can use to make complex decisions and effectively
     implement your own ACL. Enforcing authorization (e.g. the ``isGranted``
     part) will look similar to what you see in this entry, but your voter

cookbook/security/index.rst

@@ -26,10 +26,8 @@ Authorization (Denying Access)
     :maxdepth: 2
 
     voters
-    voters_data_permission
     acl
     acl_advanced
     force_https
     securing_services
     access_control
-