feat(discussion): Implement discussion moderation features

[mraman-2U]

This pull request introduces new features and improvements to the discussion moderation system, focusing on user banning, bulk delete and ban operations, and enhanced permission checks. It adds new serializers and API logic for banning users, ensures banned users are excluded from discussion stats, and introduces robust email notifications for ban escalations. Permission logic for moderation actions is clarified and strengthened, and the bulk delete task is updated to support banning users with retry logic.

Key changes:

User Banning and Moderation Logic

• Added checks in create_thread and create_comment to prevent banned users from posting in course discussions, raising a PermissionDenied error if the user is banned. [1] [2]
• Excluded banned users from course discussion user stats by filtering them out of the stats response in get_course_discussion_user_stats.

Serializers and API Enhancements

• Introduced BulkDeleteBanRequestSerializer, BanUserRequestSerializer, and BannedUserSerializer to support bulk delete and ban actions, standalone bans, and listing banned users, with validation and user normalization logic.
• Improved context generation in serializers to include course_id and ensure staff/moderator privilege checks include course staff.

Permissions and Access Control

• Clarified and expanded the can_take_action_on_spam function and IsAllowedToBulkDelete permission class to grant bulk delete and ban permissions to global staff, course staff, instructors, and forum moderators/administrators, while restricting access for students and community TAs.

Email Notifications for Moderation

• Added a new emails.py module to send escalation emails when a user is banned, using ACE (Automated Communications Engine) if available, with fallback to Django email. The email includes details about the ban, moderator, course, and content deleted.

Bulk Delete and Ban Task Improvements

• Updated the delete_course_post_for_user Celery task to support optional user banning, ban scope, moderator, and reason parameters. Added retry logic with exponential backoff for transient errors.
• Ensured database transactions are used in tasks for consistency.

Minor Improvements

• Adjusted spam URL filtering regex to improve matching in filter_spam_urls_from_html.

These changes collectively strengthen discussion moderation, provide better auditability, and improve the experience for moderators and staff

Description

Describe what this pull request changes, and why. Include implications for people using this change.
Design decisions and their rationales should be documented in the repo (docstring / ADR), per
OEP-19, and can be
linked here.

Useful information to include:

• Which edX user roles will this change impact? Common user roles are "Learner", "Course Author",
  "Developer", and "Operator".
• Include screenshots for changes to the UI (ideally, both "before" and "after" screenshots, if applicable).
• Provide links to the description of corresponding configuration changes. Remember to correctly annotate these
  changes.

Supporting information

Link to other information about the change, such as Jira issues, GitHub issues, or Discourse discussions.
Be sure to check they are publicly readable, or if not, repeat the information here.

Testing instructions

Please provide detailed step-by-step instructions for testing this change.

Deadline

"None" if there's no rush, or provide a specific date or event (and reason) if there is one.

Other information

Include anything else that will help reviewers and consumers understand the change.

• Does this change depend on other changes elsewhere?
• Any special concerns or limitations? For example: deprecations, migrations, security, or accessibility.
• If your database migration can't be rolled back easily.

[jcapphelix]

Some minor changes @mraman-2U

Also, there will be other set of PRs for edx-internal repos for new added variables ?

[jcapphelix]

This contains whitespace-only changes, can be discarded if not required for linting purpose

[jcapphelix]

Just a suggestion, we may not need to implement it

all_privileged_ids = ( moderator_user_ids | ta_user_ids | course_staff_user_ids) 
has_moderation_privilege = requester.id in all_privileged_ids or is_global_staff 

Possible change, not required strictly

[jcapphelix]

Do we need these many safety nets ? won't view.kwargs.get be enough ?

[jcapphelix]

Linting related changes ?

If otherwise, changes can be removed. Keep changes as is if linting related issues.