while this is slightly less bandwidth efficient (1 in 92 datagrams not full vs 1 in 733), this is significantly less memory-hard.
I made this decision looking at the memory pressures that 1MB chunks exert - especially on RakNet. Client-side, these resource pack chunks all hang around in RakNet memory until the whole thing is received, and it's a lot more costly to receive 733 datagrams than it is to receive 92, especially since it's much more likely that some of the 733 will disappear along the way.
If, for example, the first couple of hundred KB split parts arrived out of 1MB, and then one of the parts got lost, all the already-received parts would hang around in memory not getting processed. With smaller chunks this is much less of a problem.
I explored taking the chunk size all the way down to 1KB to reduce the bandwidth waste caused by split packets (split headers), but this made resource pack downloading unbearably slow, so it wasn't acceptable.
the old limit was made in the php5 days when performance was far worse and it was much more costly to generate chunks that weren't needed. Now it's significantly less and having a higher limit allows terrain to be sent more quickly in new worlds and to fast-moving players.
This limit really ought to go away completely but considering the technical barriers in the way it'll have to stay for now.
we really need the level 8 checks on new code now, and waiting until old code is clean is not going to benefit us much because the issues that are there already exist.
close#3456
since this is a protocol addition and not API, this belongs on stable so
that protocol changes can consistently use it without worrying about
branch compatibility.
