Fixes #14094: mc_issue_add project['name'] is not used

Thanks to Tino Böhme (tino) for contributing a patch.
Fixes #14341: SOAP API is failing due to PHP errors that are ignored by the web app.
Cleanup SOAP error handler which contained dead code.
Bug and bugnote access level checks should use project settings

Calls to config_get to retrieve configuration values should include the
relevant project ID to ensure that project-specific bugnote/bug
thresholds are taken into consideration over global settings.

An erronous use of the REPORTER constant has also been replaced. This
allows for valid/correct use of custom access levels in relation to the
$g_limit_reporters=ON functionality.
Fix #14340: Reporters can use SOAP to update bugnotes without permission

The access checks inside bugnote_update.php and
api/soap/mc_issue_api.php differed. Users were incorrectly allowed via
the SOAP interface to update the bugnotes of other users. Instead of
comparing the SOAP user's access level to $g_update_bugnote_threshold,
$g_add_bugnote_threshold was used instead.

This posed a problem because the default installed state of MantisBT is
to allow the REPORTER access level to submit bugs via the SOAP API. Thus
in the default installed state, any user who could submit a bug could
also update/modify the bugnotes of any other user.

Access checks within bugnote_update.php and api/soap/mc_issue_api.php
should now be equivalent.

Thanks to Roland Becker and Damien Regard (both MantisBT developers) for
finding and reporting this problem.
Fix #14342: mc_issue_api functions do not perform read only checks

Various SOAP functions in mc_issue_api.php did not perform checks to
ensure that read only issues are unmodifiable.
Fix #14016: delete_attachments_threshold is not checked

Roland Becker (MantisBT developer) reported the following
security/access control bug:

In a default installation delete_attachments_threshold is set to
DEVELOPER but having access level >= update_bug_threshold is enough to
delete attachments if form_security_validation is set to OFF.

MantisBT was not checking the access level of the user requesting
deletion of an attachment to an issue against
$g_delete_attachments_threshold.

The new access control logic for deleting an issue attachment is now:
1. Does the user have an access level of at least update_bug_threshold?
2. If the user is the owner of the file and
$g_allow_delete_own_attachments=OFF, does this user have an access level
of at least delete_attachments_threshold?
3. If the user is not the owner of the file, do they have an access
level of at least delete_attachments_threshold?

Also refer to issue #14015 for discussion on whether
update_bug_threshold should be part of the access control logic.

The relevant SOAP API call has also been updated.

Conflicts:
	bug_file_delete.php
Fix #14015: attachment deletion: remove update_bug_threshold check

As reported by Roland Becker (MantisBT developer):

Although configuration option allow_delete_own_attachments is set to ON
reporters cannot delete their own attachments. After pushing the delete
button you get "Access Denied"

Issue #14016 implemented correct attachment deletion access control
checks against delete_attachments_threshold. We should be using this
threshold instead of update_bug_threshold because attachments aren't
linked to the core fields of an issue -- they are frequently related to
comments (bugnotes) provided by less privileged users.

$g_allow_delete_own_attachments should now work again... safely.
Additional patch to fix #14016

First patch to fix the issue introduced access to undefined variable.
Fix whitespace in mc_issue_api.php
Fix misleading exception in mc_issue_note_update()

The error message was referring to 'Issue' instead of 'Issue Note' id.
mc_issue_note_update passing wrong param to access check function

Commit edc8142bb8ac0ac0df1a3824d78c15f4015d959e introduced proper logic
to avoid unauthorized update of bugnotes, but was passing incorrect
parameters to access_has_bugnote_level() so unprivileged users could
still update them.

Fixes #14340
Revert "Don't throw error when using db_fetch_array on empty resultset"

As per grangeway's comment and confirmed by vincent_sels (original
issue's reporter), this change is actually not necessary.

This reverts commit 33170d2d54643e63b1a60b021dcb0cbbb45e4157.

Affects #14336