Remove status check for metadata update queue watching

[peppy]

Went to check on this since there’s been a few reports recently of beatmaps in lazer getting stuck in “qualified” state that have since been ranked. Related code: web / spectator / web-10 queue processing

I think this is an issue with the status=2 check and parallel processing of the queue. Imagine this scenario:

• osu-web inserts newly ranked beatmaps (let's say 10 get ranked at once) with status=1
• web-10 processes the queue with its every-minute-cron
• one beatmap takes a few minutes to generate due to having very large mp3
• a second web-10 cron process fires up and also begins processing, quickly processing beatmaps with short mp3s that are pending
• **spectator-server skips over the long mp3 entry and continues processing due to tracking status=2 only
• first process finishes and updates long mp3 entry to status=2 but spectator no longer cares about it because it's already tracking a newer ID

There's no reason for us to be waiting for completion of the queue items, as at the point of qualified -> ranked it's just a failsafe to ensure thumbnails/previews are in a pristine state, so the best solution is to drop this check.

Probably closes ppy/osu#21332

[bdach]

Hypothesised scenario sounds plausible. From what I know of the submission process, and the linked web-10 queue processing code, the client should not need to care about the status of the processing.

By the time a bss_process_queue entry exists, all of the metadata, which is the part that the client will read from online sources, should already be correct; the client should not care about the thumbnail or the preview track, and star rating / score attribute processing is not relevant because the client will recalculate all of that locally anyway.