Send the server's warp list to the open source client #1503

Is your feature request related to a problem? Please describe.

The open source client (MuMain) takes its warp list (the M window and /warp <name>) from its own data file, movereq_<lang>.bmd. That file follows Webzen's Season 6, so warps that OpenMU has and Webzen doesn't, like Crywolf (26) and Loren Market (44), can't be selected. Adding them to the file doesn't work either: MuMain is also used with Webzen's servers, which can't warp there. That's why sven-n/MuMain#1026 was reverted in sven-n/MuMain#1057.

The warp list belongs to the server. OpenMU keeps it in GameConfiguration.WarpList, admins can change it and update plugins do change it, so the client can't know it from a static file.

Describe the solution you'd like

A new packet, only for the open source client, with the server's warp list. MuMain uses it instead of its file when it arrives. A Webzen server never sends it, so nothing changes there.

• WarpListExtended, C2 F5 09, server to client. F5 is the family of the open source client packets; 09 is free and odd, like the other server-to-client packets of the family.
• Count (byte), then one 44-byte entry per warp:
  • Index (ushort): WarpInfo.Index, what the client sends back in WarpCommandRequest (C1 8E 02)
  • MapNumber (ushort): the map of the warp's gate
  • LevelRequirement (ushort): as configured; the client applies the class reduction (DL, MG, RF) as it does today
  • 2 reserved bytes
  • Costs (uint): zen
  • Name (string, 32 bytes, UTF-8): WarpInfo.Name in the player's culture
• Sent once after the character entered the world (CharacterSelection → EnteredWorld), through an IPlayerStateChangedPlugIn like ShowShopCurrenciesAfterEnterWorldPlugIn. Map changes don't send it again.
• WarpInfo.IsWarpable (default true, added after the review in feat(warps): send the warp list to the open source client #1504): when it's off, the warp isn't in that list and the server refuses it for players; game masters can still use it. A new season 6 configuration has it off for the warps the original warp window doesn't offer (Crywolf, Loren Market, the second LaCleon warp); an optional update does the same for existing configurations.
• A view plugin with [MinimumClient(106, 3, ClientLanguage.Invariant)] writes it. There's no implementation for the original clients, so they never get it (same as ShowShopCurrenciesExtendedPlugIn).

On the MuMain side: warps that exist in the file keep their translated names and position, with the server's level and zen; warps only the server has are added with the server's name; warps the server doesn't have are left out. MuMain reads the message by hand, like the other F5 messages, so it doesn't need a new release of MUnique.OpenMU.Network.Packets.

Describe alternatives you've considered

We read #1212 and sven-n/MuMain#722. The quick warp module there is the first UI module, but decision 2 says a module window doesn't replace a built-in one. So even with #1212 done, the M window and /warp would keep using the client's file, and the quick warp module would be a second warp list next to it. Given that, and the size of #1212, we went for this small change, which fixes the built-in window and /warp now.

If you'd rather have the warps end up as a module, the M key could open that module when the server offers it. That changes decision 2; in that case we'd be glad to help with #1212 wherever you say.

Additional context

Both sides are implemented and were tested together on a local server: #1504 (OpenMU) and sven-n/MuMain#1110 (client).