Build: explore these Celery's features

[humitos]

I haven't tested them yet, but look promising and more accurate than our current approach.

1. raise Reject(requeue=False) on duplicated builds
2. use a global task_cls (https://docs.celeryproject.org/en/latest/userguide/tasks.html#app-wide-usage) to logs actions
3. use CELERY_IMPORTS to register the tasks (https://docs.celeryproject.org/en/latest/userguide/configuration.html#std-setting-imports)
4. use CELERY_TASK_IGNORE_RESULT=True since we are not using the result at all
5. review time_limit from DOCKER_LIMITS and for Celery task so we can handle them nicely at on_timeout. In the last case, we will be able to do a nice cleanup (related to Builds: check celery and redis before marking a build as stale #8269)

[humitos]

This setting would be useful as well to avoid zombie builds when the worker is killed by ASG, https://docs.celeryproject.org/en/stable/userguide/configuration.html#task-reject-on-worker-lost

[humitos]

I'm not sure why, but I cross-linked this issue in this PR #9096 and it's not shown here for some reason 🤷🏼. So, I'm commenting here.

[ericholscher]

I'm fine with this PR. Actually, I opened #8941 and wrote that we should use CELERY_TASK_IGNORE_RESULT=True globally so we don't store the results since we are not using them and they could generate these kinds of problems.

This seems like a good thing to do, if we aren't using the result 👍

[humitos]

We have been happy with Celery lately and I don't think we need to "improve" it with these features. I'm closing it for now.