Do not consider in progress requests with no manifests when checking build requests

[mertbugrabicak]

When we have an in progress manifest generation (either build or release), it will not have any manifests produced, so if a request gets stuck in progress, it will stay like that without any manifests. So the current attempt at filtering of build manifest requests will accidentally include "in progress" release requests in its check for if the last build manifest was successful.

This means when we have a stuck-in-progress release, the current filter isn't able to do a check if it's a build manifest and by default considers it a build manifest to check if it was successful. This change should throw out the in progress requests from consideration, so it will catch the one before and check if that one was successful.

This would hopefully allow us to re-do release manifest generations that have been stuck in progress if their last build manifest request was successful.

Edge case to consider
If it gets triggered when there's build manifest still in progress, it would ignore it and still do the last successful one. This makes sense to me, even if it could be undesirable. The service will work with what it has.

Sorry if none of this text makes sense 🤣 I hope the code change itself gives more context

[mertbugrabicak]

After discussion, we might actually just time out / fail the stuck in progress ones, so this may not be needed