Make tests pass on PostgreSQL

This appears to be a problem with db_merge() not working on PostgreSQL when the primary key is a serial field. We use essentially the same code for both roles and file downloads, since they are both file features, which is why these tests are the ones that fail in PostgreSQL.

This seems to be a problem in core - all the db_ functions EXCEPT db_merge are tested against tables with serial and non-serial primary keys, but db_merge() is only tested in the case of non-serial primary keys. db_merge() is the recommended replacement for drupal_write_record() which we used to use in D7 for roles and files, but drupal_write_record() has always had this known problem with PostgreSQL and serial primary keys. There have been many issues about this, but they have all been closed and "fixed" in core by not using db_merge() when core has a serial primary key, thereby avoiding the issue instead of addressing it.

Short of a core fix for db_merge(), we'll probably just have to test the key and do a conditional db_insert()/db_update(). Yuck, but it will work.

Let's do this for beta.

Let's test my theory ...

Again ...

See if I can debug the package test ...

Another debug attempt.

Another wild guess as to what may be going wrong ...

Success! PostgreSQL tests are now passing for the first time!

Lessons learned:

1. db_merge() does not work on PostgreSQL with serial primary keys. Normally, you would assemble an array of fields to write, one of which was the primary key. If the key was null, then db_merge() would call db_insert() to create a new record. If the key was set, db_merge() would call db_update() to modify the record. This works for non-serial keys, and works well on MySQL with serial keys, but on PostgreSQL with serial keys if the key is null then you CAN'T pass it to db_merge() as one of the fields, while if it's not null then you MUST pass it. In other words, on PostgreSQL you must pass different arguments to db_merge() depending on what the key value is. Because you have to test this, you will already know whether you need to call db_insert() or db_update(), so it's more readable and cleaner to just explicitly call db_insert() or db_update() yourself. The only utility of db_merge() is to have the same code whether you're doing an update or an insert, but that can't work with PostgreSQL. This was needed to fix the uc_role and uc_file failures.
2. SELECT doesn't guarantee an order for returned records. Although the order will always be the same with a given database, using another database such as PostgreSQL is likely to (and in fact DOES) give you a different order. So if your tests rely on the order of records, be sure to add an ORDER BY clause to your SELECT. This was needed to fix the uc_fulfillment failure, where the packages returned by PostgreSQL were listed in the opposite order than with MySQL, so deleting the "first" package gave different results with the different databases.

The first one feels like a bug in the Postgres driver - maybe it should be reported against core?

Yes it should, I just don't know if I have the energy to take on what is probably a multi-year task of trying to get that fixed in core.