Feat: Handler Cleanup and Loading Screens

[RyanYappert]

Cleans up a bunch of handlers so that we're no longer manipulating buffers in the middle of them like savages.

Boring Stuff

• A bunch of PacketHandlers have been upgraded to RequestPacketHandlers. IBuffer.WriteFoo has been banished from the handlers.
• A bunch of packets have been (partially) decoded. In general this does not implement any new functionality; most of these were returning blank lists like QuestGetPackageQuestListHandler, but this may be useful in reading pcaps.
  • Also decoded are some useful CONNECTION group notices.
• Login errors have been adjusted. Since these are now LoginRequestPacketHandlers, they can now be straightforward throw ResponseErrorExceptions. Some new error codes have been invented. What may have been A-1 ERROR_CODE_FAIL may now be an S-6011 ERROR_CODE_AUTH_LOGIN_FAILED or similar, so we can diagnose these more clearly.
• To support the new login errors, GetErrorMessageListHandler has been adjusted. This is pending a rework of the error code asset per More verbose error messages #610 . Turns out you can break up the error list notice into smaller chunks, so we can make the error messages as big as we want without bumping up into packet size limits (ushort.MaxValue bytes)

Fun New Stuff

• LoadingInfoLoadingGetInfoHandler now uses a new LoadingInfoAsset, pulled from LoadingInfo.json. This lets you put whatever obnoxious pat-on-the-back text in loading screens, with some levers to control scheduling and priority.
  • A default example has been included, including obnoxious pat-on-the-back text.

Checklist:

• The project compiles
• The PR targets develop branch

[alborrajo]

Im worried about this kind of logic in the serializer, maybe this should be done by the handler

[RyanYappert]

I feel like the point of the deserialized object vs. the raw buffer is that the handler shouldn't have to think about the sizes of the byte array. I haven't tested whether or not the client will crash from a buffer overrun if this isn't properly sized (the packet does have the size of the used portion in it), but if it will, then forcing the handler to do that check feels inappropriate.

Also making the handler do this requires exposing a obj.Padding field which also feels wrong.

[alborrajo]

ditto