rpki-client: shuffle the order in which Manifest entries are processed

[Job Snijders]

At the moment work items are enqueued in the order the CA intended them
to appear on a Manifest. However, I don't see any benefit to letting
third parties decide the order in which things are processed. Instead,
let's randomize: ordering has no meaning anyway, and the number of
concurrent repository synchronization operations is limited & timeboxed.

As they say, a fox is not taken twice in the same snare. :-)

OK?

Index: mft.c
===================================================================
RCS file: /cvs/src/usr.sbin/rpki-client/mft.c,v
retrieving revision 1.96
diff -u -p -r1.96 mft.c
--- mft.c       29 Jun 2023 10:28:25 -0000      1.96
+++ mft.c       2 Sep 2023 22:35:10 -0000
@@ -233,6 +233,7 @@ mft_parse_filehash(struct parse *p, cons
        int                      rc = 0;
        struct mftfile          *fent;
        enum rtype               type;
+       size_t                   new_idx = 0;
 
        if (!valid_mft_filename(fh->file->data, fh->file->length)) {
                warnx("%s: RFC 6486 section 4.2.2: bad filename", p->fn);
@@ -256,8 +257,15 @@ mft_parse_filehash(struct parse *p, cons
                p->found_crl = 1;
        }
 
-       /* Insert the filename and hash value. */
-       fent = &p->res->files[p->res->filesz++];
+       if (filemode)
+               fent = &p->res->files[p->res->filesz++];
+       else {
+               /* Fisher-Yates shuffle */
+               new_idx = arc4random_uniform(p->res->filesz + 1);
+               p->res->files[p->res->filesz++] = p->res->files[new_idx];
+               fent = &p->res->files[new_idx];
+       }
+
        fent->type = type;
        fent->file = fn;
        fn = NULL;