Queue (multiple redundant job submission) + UI file upload false WHERE error fixes

What type of PR is this?

🎮 Feature
🐛 Bug Fix

Description

A minor change in files.go to fix the false error "WHERE condition is required": This was happening because the handler was trying to upload tags for existing files without a where condition. I moved it inside the block where we upload tags only for newly uploaded files, and for existing file, only add a user_file record.
Fix for multiple redundant job submissions when only one job is submitted: I changed queue initiated processRayJob calls to worker initiated calls. Also fixed spinning up endless workers by adding a once check, so we only spin up MAX_WORKERS number of workers. With this fix, going forward the workers, when free, calls the processRayJob. And the method fetchOldestQueuedJob is now updated to fetch and update the oldest queued job to "Pending" state. This introduces a new state "Pending" into the list of possible job statuses.
Similar to /queue-summary, there is now a /worker-summary that shows the job handled by each worker. This was introduced to double check that the same job is not processed by multiple workers. (This should already be fixed with the fetch and mark as pending change).
Stopping dangling jobs after an hour: With Ray Services, there is an issue where during the initial boot up, jobs more than the MAX_WORKER value get picked up, and the excessive jobs go dangling as it proceeds with the queue to the next set of jobs. This is fixed by introducing an intervention where the queue fetches the oldest running job and marks it as "stopped" which is different from "failed". This change introduces a new state "stopped" into the list of possible job statuses. It is important we are able to differentiate between ray failed jobs and manual intervened stopped jobs for our analysis later.

Note: This above change will be incorporated with the upcoming stripe PR to not charge users for manually stopped dangling jobs.

Steps to Test

Successful test should spin up only MAX_WORKERS no. of containers per service. And the remaining jobs should stay in queued state. There shouldn't be endless scaling up (till the max scale up capacity) and showing all the jobs submitted as running. Dangling jobs should be marked as stopped after an hour. Dangling jobs stopped example: (this can be tested by setting 1*time.Hour to a lesser time infetchAndMarkOldestRunningJobAsStopped function

labdao / plex

Queue (multiple redundant job submission) + UI file upload false WHERE error fixes #1002

What type of PR is this?

Description

Steps to Test