refactor(Core/ServerMail): Refactor to Dedicated Manager Class with Multi-Item & Condition Support

[Kitzunu]

Changes Proposed:

1. Core Cleanup
   • Move all ServerMail logic from ObjectMgr into a new dedicated ServerMailMgr class
   • Move faction logic for money from SendServerMail into the script
2. Separation of items into a new table
   • Create a new mail_server_template_items table
   • Allows to send multiple items in one mail
   • Separate items per faction Alliance/Horde
3. Separation of conditions into a new table
   • Create a new mail_server_template_conditions table
   • Allows to use multiple conditions for one mail
   • Available condition types
     • Minimum playtime (playerLevel >= condition)
     • Minimum playtime (playerPlayTime >= condition)
     • Rewarded quest
     • Earned achievement
     • Earned reputation (playerReputation >= conditionState)
     • Faction
     • Race
     • Class
4. Updated ServerMail loading
   • Move item and condition loading to their own functions
     • LoadMailServerTemplateItems()
     • LoadMailServerTemplateConditions()
5. Reworked eligibility check
   • Player needs to pass all conditions to be eligible for the mail
   • All players are automatically eligible if no conditions exist for a server mail template.
6. Updated foreign keys
   • For table mail_server_character, mail_server_template_conditions, mail_server_template_items foreign key with on delete cascade is added for automatic removal of entries if mail_server_template.id is deleted.
7. Database changes

table	change
mail_server_template	Removed itemA, itemH, itemCountA, itemCountH, reqLevel, reqPlayTime
mail_server_template_items	New table to hold items.
mail_server_template_conditions	New table to hold conditions.
mail_server_character	Added foreign key to mailId with ON DELETE CASCADE

mail_server_template_conditions

conditionType	conditionValue	conditionState
Level	minimum required level	always 0
PlayTime	miniumum required play time in milliseconds	always 0
Quest	quest id	0,1,3,5,6 (None, Complete, Incomplete, Failed, Rewarded)
Achievement	achievement id	always 0
Reputation	faction id	0-7 (Hated, Hostile, Unfriendly, Neutral, Friendly, Honored, Revered, Exalted)
Faction	0/1 (Alliance/Horde)	always 0
Race	Bitmask (Human 1, Orc 2, Dwarf 4, Night Elf 8, Undead 16, Tauren 32, Gnome 64, Troll 128, Blood Elf 512, Draenei 1024)	always 0
Class	Bitmask (Warrior 1, Paladin 2, Hunter 4, Rogue 8, Priest 16, Death Knight 32, Shaman 64, Mage 128, Warlock 256, Druid 1024)	always 0

Migration queries (included in the SQL script)

INSERT INTO `mail_server_template_items` (`templateID`, `faction`, `item`, `itemCount`)
SELECT `id`, 'Alliance', `itemA`, `itemCountA` FROM `mail_server_template` WHERE `itemA` > 0;

INSERT INTO `mail_server_template_items` (`templateID`, `faction`, `item`, `itemCount`)
SELECT `id`, 'Horde', `itemH`, `itemCountH` FROM `mail_server_template` WHERE `itemH` > 0;

INSERT INTO `mail_server_template_conditions` (`templateID`, `conditionType`, `conditionValue`)
SELECT `id`, 'Level', `reqLevel` FROM `mail_server_template` WHERE `reqLevel` > 0;

INSERT INTO `mail_server_template_conditions` (`templateID`, `conditionType`, `conditionValue`)
SELECT `id`, 'PlayTime', `reqPlayTime` FROM `mail_server_template` WHERE `reqPlayTime` > 0;

This PR proposes changes to:

• Core (units, players, creatures, game systems).
• Database (SAI, creatures, etc).

Issues Addressed:

• closes Feature: Allow send more than 1 item in server mail #11446

Tests Performed:

This PR has been:

• Tested in-game by the author.

How to Test the Changes:

Warning

When testing, remove the SQL file from the updates folder. Otherwise, if you restart your server, the auto updater will run it again which will result in errors.

• Test to ensure eligible players receive correct mail when logging in.
• Test mails with multiple items.
• Test mails with conditions.
• Test mails without conditions work correctly (no conditions = mail always eligible).

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

[Kitzunu]

I think this PR is done. I have updated the description with in-depth detail of what has changed

[Takenbacon]

Why not store as the type (uint8) in the database rather than string and having to manually convert?

[Kitzunu]

Due to storing it as an Enum in the database for easy readability. But if that is overkill we can swap it, sure

[lineagedr]

Imo it's best to do the validation above where the rest of the validations are.

[Kitzunu]

I dont really understand? We need it after the other validation to know where to push it.
Also the else statement should in reality never be able to hit since we use enum in the database for faction

[Kitzunu]

I have addressed most reviews, thanks for them!
I am learning a lot about things, I appreciate the patience