fix(Core/Auction): Fix disconnect when people try to buy/sell to many items

[skelUA]

Changes Proposed:

This PR proposes changes to:

• Core (units, players, creatures, game systems).
• Scripts (bosses, spell scripts, creature scripts).
• Database (SAI, creatures, etc).

Issues Addressed:

• Closes Rework auctionhouse Update causes people to be kicked if buy to many items at once #21140

SOURCE:

The changes have been validated through:

• Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
• Sniffs (remember to share them with the open source community!)
• Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
• The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

• Tested in-game by the author.
• Tested in-game by other community members/someone else other than the author/has been live on production servers.
• This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

• This pull request can be tested by following the reproduction steps provided in the linked issue
• This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

Known Issues and TODO List:

• [ ]
• [ ]

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.

[sudlud]

if 100 is sufficient, we could remove the packets from the list so it uses the default value for those

[Vtkachenko-Informa]

Some users and addons needs more 200 packets

[TheSCREWEDSoftware]

I shall ping @Takenbacon for some input

[TheSCREWEDSoftware]

I shall ping @Takenbacon for some input

Context:

AH Query packets were added to the throttler (here: https://github.com/azerothcore/azerothcore-wotlk/blob/master/src/server/game/Server/WorldSession.cpp#L1551-L1553). I'm guessing a buy also seems to send a query request. We can just increase the limits for now, it was noted in the AH PR that the current packet throttler implementation is not ideal for this use case to begin with but that'll need a good bit more work to properly handle.

[Takenbacon]

Some users and addons needs more 200 packets

Which addons and were they designed to work on retail 3.3.5? I have a very hard time believing a non-private server addon would allow for sending 200 query packets a second, retail servers are generally way more strict than we are and would cause disconnections.

Either way, increasing the limit is a bit of a mixed bag but I think it is the right move for now as a temporary solution. The concern is a malicious user could theoretically spam query opcodes and since the AH queries are quite slow with a big AH it will backlog the searcher threads effectively stopping AH searches. In the long run we need a generic solution for queuing up certain packets (not just AH but a couple other systems as well), but to do it properly and cleanly will take a little bit of work.

[skelUA]

Some users and addons needs more 200 packets

Which addons and were they designed to work on retail 3.3.5? I have a very hard time believing a non-private server addon would allow for sending 200 query packets a second, retail servers are generally way more strict than we are and would cause disconnections.

Either way, increasing the limit is a bit of a mixed bag but I think it is the right move for now as a temporary solution. The concern is a malicious user could theoretically spam query opcodes and since the AH queries are quite slow with a big AH it will backlog the searcher threads effectively stopping AH searches. In the long run we need a generic solution for queuing up certain packets (not just AH but a couple other systems as well), but to do it properly and cleanly will take a little bit of work.

Test on auctinator try to cancel more than 100 auctions

[sudlud]

i would imagine that you can set auctionator to some throttling limits for this?

also my comment from above still stands - why use magic number 200, just remove the packet type from the special handling and let it use the default value of 100. but maybe there's other opinions on this

[Takenbacon]

I did a little bit of testing with Auctionator, and while I'm not familiar with the addon, I am unable to reproduce any opcode spam with it. You'll need some more in depth reproduction steps. Also, you should know Auctionator technically isn't a 3.3.5 addon. It's 4.x back ported for private servers which is already questionable enough as is.

[skelUA]

I did a little bit of testing with Auctionator, and while I'm not familiar with the addon, I am unable to reproduce any opcode spam with it. You'll need some more in depth reproduction steps. Also, you should know Auctionator technically isn't a 3.3.5 addon. It's 4.x back ported for private servers which is already questionable enough as is.

try to add 200+ items on auction and cancel they all from auctinator