Implement worker queue / cron system to chronologically process fleet missions

[lanedirt]

Current Situation

• Fleet missions are processed during user requests via PlanetService::updateFleetMissions().
• This approach works for the current user but causes issues with multiple players and missions.

Problem

Inconsistent mission processing

The current system can lead to inconsistent mission processing:

1. Player A schedules an attack on planet [1:1:1] to arrive at 10:00.
2. Player B schedules an attack on the same planet [1:1:1] to arrive at 10:15.
3. If Player A logs off and Player B stays online, the 10:00 mission isn't processed until Player A returns.

This creates potential conflicts and unfair gameplay scenarios.

Large battle processing

Large battles with millions of units can take a relatively long time to process. PR #517 introduced the Rust Battle Engine which is up to 200x more performant than the PHP Battle Engine, which already saves a lot of time. However there are still usecases where even the Rust Battle Engine takes up too much time to process during a user request.

E.g. issue #503 mentioned a usecase where the defender player had 28M destroyer units on the planet. With a battle of 15M attacker units and 28M defender units the Rust Battle Engine takes up to 800MB of memory and 10+ seconds to process.

Moving over the fleet mission processing to the worker queue will prevent user requests from hanging for multiple seconds in case of very large battles.

Proposed Solution

Implement an independent worker queue / cron system for background fleet mission processing.

Requirements

1. Process fleet missions in real-time, independent of user logins.
2. Handle missions in strict chronological order.
3. Prevent conflicts between simultaneous or closely timed missions.

Key Considerations

• Aim for near real-time processing: missions should be executed within 1-3 seconds of their scheduled time.
• Ensure scalability to handle multiple concurrent missions across the game universe. E.g. missions for different planets that do not conflict with each other can be processed concurrently and do not necessarily have to wait for each other.
• Implement logging and error handling for mission processing.
• Consider edge cases like server downtime or processing delays.

Next Steps

1. Design the background processing system architecture.
2. Choose appropriate technologies (e.g., Redis for queue, Laravel's job system).
3. Implement a prototype and test with various scenarios.
4. Gradually migrate from the current system to the new background processing system.

Additional Notes

• This change will significantly improve gameplay fairness and consistency.
• May require adjustments to other game mechanics that interact with fleet missions.
• Note: PHP and webserver timeout issues were increased in [BUG] Extend PHP timeout from 30sec to 300sec to support larger battle processing #577 because of large battles taking longer than 30 seconds to process. When everything is moved to a background worker, these timeouts may be reduced again.

[jackbayliss]

Perhaps something similar to the highscores could work for this, but a queue worker rather than the scheduler :)