Security uploads fails when assume that an accepted ".orig" file will be available before the next cron.daily run

[Celso Providelo]

This incident happened today when a new version of firefox was uploaded for dapper-security & breezy-security in the same batch. The second source upload presumed (*correctly*) that the orig was already present in the archive, since it was uploaded by the first one, and doesn't included it.

However, Soyuz isn't able to lookup an file that isn't *published* yet, so the second source upload was rejected because the implicit orig was not found.

[Celso Providelo (cprov)]

After some investigation, I see that the issue could be solved by *processing* the accepted sources, creating a PENDING publish record just after we accept the it. So the *process-accepted* task will remain only for binaries and custom uploads.

This change will only affect file lookup, there is no side-effect for high-level sources lookup (like UI, building, etc), since it's still requiring a record in PUBLISHED state.

[Celso Providelo (cprov)]

It has severe impacts in security uploads turnaround time. A good FiF candidate.

[Christian Reis (kiko)]

Are we sure this has no side-effects apart from the positive one we're considering?

[Celso Providelo (cprov)]

Well, I'd say so.

The only collateral effect might be the early publication of the custom-part of the uploads on disk during mirroring process.
But, AFAICS, even if it is possible in the DB model, this practice isn't used currently, i.e, stored source uploads don't contain any custom part:

{{{
launchpad_prod=> SELECT drq.id from distroreleasequeue drq, distroreleasequeuesource drqs, distroreleasequeuecustom drqc where drq.id = drqs.distroreleasequeue AND drq.id = drqc.distroreleasequeue;
 id
----
(0 rows)
}}}

I think it will be safe to do If we enforce this condition with DB constraints and maybe also upload-policy parameters (source uploads must be "truly_source_only")

[Celso Providelo (cprov)]

concept proof done in my `bug-77853`

[Celso Providelo (cprov)]

RF 4372