user profile: remove odd non-showing, non-functional delete button

'Site.User.Manage' does not exist, so the button can never show.
(FIXME: this doesn't cause any error or warning).

At the moment you can only view your own profile,
but you're not allowed to delete() your own user,
so this button wouldn't have worked.
And if you could view other user's profiles,
the condition for displaying the button would
still need updating to test for this condition.

Redirecting into the admin area looks slightly odd.
Also using GET for "unsafe" actions is not recommended.
And marking up what looks like a button as a HTML
anchor element is not completely ideal.

I suspect there will be an "unregister me" function in future. But that
could equally be implemented in the user.php controller, so it wouldn't
need to use a clunky cross-controller link.  (E.g. it could be a
secondary submit button on the profile form).
user settings controller: cleanup unnecessary _remap()

This was also allowing users to invoke the _private_ methods,
as well as the public ones.
user settings: restore the "restore" button for deleted users

It seems to have been overlooked during a rewrite.
user settings controller: unpublish broken public methods used by index()

 * ban()
 * activate()
 * deactivate()

...all have no view file, so they won't work as public methods.  And
the second two only accept arrays, which CodeIgniter doesn't provide.

 * delete()
 * restore()
 * purge()

...redirect to index(), which does have a view file.  However, they still
do the redirect when called by index(), dropping any filter parameter
which has been set by the user.

I moved the precondition checks into index() (and made them consistent).
There was so much repeated code there, and it didn't make enough sense
to keep.  Maybe we'll need public versions of the other methods at some
point, and it'll need refactored again.  But it should be easier to see
what you're doing if they're not littered with dead code paths.
user settings: preserve filter parameters when performing actions

E.g. after activating one user, you should stay in the same tab
where you selected that user (All Users, By Role, or wherever).

Noticed after testing the previous commit - I removed an obstacle in some
of the actions, without realizing that it didn't work properly for any of
them.
Remove unused unique() callbacks - CI is doing this check for us already

These public methods were not used.  That's ok, because we're using
the form validation's built-in uniqueness check.
All controllers: Unpublish internal functions

Unpublish functions which aren't intended to be public CodeIgniter methods.

Form validation functions need to be public, but we can still stop
CodeIgniter from calling them by prefixing them with an underscore.
roles module: matrix() is a public HMVC method - fix its comment
roles module: small cleanup where we "grab the current role model name"
BF_Model, config_file_helper: Don't strip "submit" and "func" fields

In this commit, we stop cleaning these fields out in BF_Model and
config_file_helper.  Two users of BF_Model needed modifying to clean up
their own POST data.  None of the config_file_helper users relied on
this behaviour.

It's so magic we didn't know how to document it.  So magic we forgot
about "func", which is not cleaned consistently and not used anywhere.
So why did I even notice, you ask?

I want to change the delete link inside an edit form into an secondary
submit button, because standard GET links don't benefit from
CodeIgniter's protection against CSRF.  There might be better ways to
do it, that e.g. don't send all the un-needed form data when deleting,
but I'm going ahead because it

 + works
 + has the advantage of not actually being wrong
 + is obvious what the code is doing
 + avoids me having to hack up something more complex with javascript

Given that, I need to distinguish the two submit buttons.  Using value=
doesn't work, because I need <button> to allow for the delete icon, and
IE7 doesn't send the value for <button>; it sends the element content
instead.  Grr, IE.  So I use name="delete", and distinguish the main
submit button with name="save" (matching the usual save_X() method).

This means the main submit button is no longer called "submit", we don't
clean it out of the POST data, and we choke on it.

Another entertaining effect of this redundant naming convention: if you
have a form F containing a control with the name "submit", the control
will be accessible as F.submit - making it impossible to call the DOM
method F.submit().

And hey, someone might try to use a database field called "func" someday.

"Convention over configuration" is a fine idea, but this specific magic
doesn't look like a good implementation of it.

We're not even taking advantage of this convention in the output of the
modulebuilder (which could be said to serve as a form of documentation).
Perhaps because passing _POST directly to update() would allow users to
update any field - including delete flags, dates, or id... possibly
bypassing naive form validation code.  I don't think it's a big problem
where this is currently used in the core, but it does make me feel
uncomfortable.
emailer tests: don't disable profiler

This is not commented, documented as a requirement for client code,
or done elsewhere e.g. when sending activation emails.
emailer: "3 (x) records deleted." should be "3 records deleted."
log module: "3 Log files deleted" should be "3 log files deleted"

I don't know about the Persian; I've left that unchanged.
The position of %d appears to match lang('activity_deleted') [1],
so it should at least be in the right logical position.  The question is
whether the translator noticed that the string has a numeral prepended -
if they didn't, then the translation may not be quite right.

[1] Unless it involves some invisible control character.
Enable CSRF protection

Description from config.php:

"Enables a CSRF cookie token to be set. When set to TRUE, token will be
checked on a submitted form. If you are accepting user data, it is strongly
recommended CSRF protection be enabled."

Otherwise, if you visit another site while you're logged in to Bonfire,
the other site can initiate arbitrary actions on Bonfire.
Turn "unsafe" GET links into POST form buttons

CodeIgniter: "You can enable csrf protection... If you use the form helper
the form_open() function will automatically insert a hidden csrf field in
your _forms_."  [emphasis mine]

Also: HTTP/1.1: The GET method SHOULD NOT be used for "unsafe" actions.

Also HTML buttons will be seen as such by screen readers,
without the need for hacks like WAI-ARIA.

(I skipped logout.  There was enough here already.
It's not as important - Google don't bother about it either :).

Important implementation details:

 - We need <button type="submit">, because <input type=submit value=...>
   can't include a delete icon on the button.

 - <button name="action" value="delete" ...> DOES NOT WORK IN IE7.
   It posts the content of the button element, instead of the value.

 - We can use <button name="action_delete" ...> - the prefix
   may be a good idea if we need to tell apart a couple of different
   forms which post to the same controller method.

 - If we're not setting a value, it'll be empty (outside of IE7),
   so the natural test would be isset($_POST['action_delete']).
   [Anyone know what the point of using input->post() is?].

Also guard settings/emailer/test against GET.  Currently it's broken in
a default install (see issue #540) but it will be a problem if a Bonfire
site creates the file themes/admin/ajax.php (or maybe they upgraded from
an earlier version and didn't delete old files).
permissions module: remove (insecure) unused delete method

GET requests of this method can bypass CodeIgniter's protection against
CSRF.
Merge branch 'valid-4-escape-source-audit-v2' into audit-2-public-methods-v2

Conflicts:
	bonfire/application/core_modules/activities/views/reports/index.php
	bonfire/application/core_modules/activities/views/reports/view.php
Merge from sourcejedi
fix issue with outputting a variable
Fixing issue with the CSRF for Ajax testing of Email - might need changing