Issue: min_packet is a bit extreme

A lot of users have been having issues with the MIN_PACKET requirements in the latest release. For most people prior, VaultWiki would install fine, even with the default value. Perhaps a 32M requirement on vBulletin is a bit much.

So for vBulletin, I have added a dynamic requirement that is calculated based on the most expensive query in terms of packet size that vBulletin has: the query that caches phrases for each language. We assume that the user has custom phrases (not linked to any product), which means that language ID:0 is the most expensive language.

From there we build the query that would normally be used to cache phrases for this language, and instead of executing it, we count how many bytes the command takes up.

We overestimate the number of VaultWiki phrases by 20%, to accomodate future product growth, and we add the number of bytes needed to add that to the query.

We then make sure there is at least 512KB of free packet space, so that the user can feasibly install other add-ons in the future and to accomodate future growth of vBulletin itself.

The number we find is the resulting packet requirement to install VaultWiki.

As an example, our web site contains over 21,000 unique phrases that together take up over 2.2MB. When prepared for this query (serialization adds a lot of bytes) and adjusted using this formula, our MIN_PACKET requirement would be 4M.

Note that our web site is not particularly add-on heavy. Our large add-ons are VaultWiki and Project Tools, along with about 10 small add-ons with less than 100 phrases each. This is probably a typical scenario, but there will be sites that have more or have less.

Additionally, the packet requirement will now only be considered during the initial installation of VaultWiki 4 under vBulletin, due to this calculation being nearly as expensive as executing the query.

These changes are applied in the next release. Unfortunately if you still get a MIN_PACKET not met error during installation after the next release, the only option you have is to increase your max_allowed_packet, since the requirement is already based on your actual resource usage.