Add Domain ID into original index rather than add new and add upgrade step to fix index as it is a unique index originally

Fix upgrade step and Contact Selector Test failure

The value is passed to the api - which can handle an array. Also it doesn't need
it to be loaded if missing

Any cases of a value of '' have been filtered out before it gets here and
1) we no longer need to load additional dat when calling an api update (e.g we
don't need to worry the api will wipe the existing organization_name
inappropriately on update these days)
2) We can rely on the db default to ensure privacy options
are set to 0 if not passed in

This code is from the profile code that used to share with this.
In that code the contact_sub_type might be 'hidden', not so in imports. Also
the contact_type is already known by this point with imports.

Remove

Unlikely to have been used since 2010.

Using random_bytes is both faster and more secure than md5(uniqid(rand(), TRUE)). It is possibly also easier to read, in the sense that it is more obvious that it returns hexadecimal encoded random bytes.

I did not find an instance where guessing the random identifier would result in a security vulnerability. So this change does not have direct security impact as far as I know. It's more of a best practice thing and I hope people copy paste the new, secure way of generating random bytes when creating identifiers for security-sensitive stuff, instead of copying the old, insecure way.

In some test files the lengths of the random strings are one character longer. E.g. I replaced `substr(sha1(rand()), 0, 7)` with `bin2hex(random_bytes(4))`. The length did not seem very important here, so I don't think this matters.

I haven't tested all changed code. I rely on unit tests, and that the code generates a random hex string of a certain length before and after I replaced it.

I also looked into the SQL statements that use MD5(RAND()). These should be replaced by HEX(RANDOM_BYTES()), but this is only available starting in MariaDB 10.10, and we require 10.2.

Updates code to use preferred newer PHP function

Custom groups with no enabled fields should not appear
on the contact summary screen.

This looks to have recently regressed in core as well,
so I'm fixing it in both places.

Updates code to use preferred newer PHP function

Ensure contributionSummary is assigned to the template and
check if it is empty

The `empty()` function will automatically handle the case where the first part
of the expression is not set, so there's no need to add an extra call to `empty()`.

A few forms present a dropdown for "From Email Address",
and most of them were not correctly setting the default.
I investigated and found a couple causes:

1. Some forms just didn't bother to set it
2. Some forms *tried* to set it, but it got mangled by the html purifier

For the not-even-trying forms, a pretty simple catch-all solution is to
put the default at the top of the list, thus the change to CRM_Core_BAO_Email::domainEmails

For the ones that were trying and failing, I added the field to
getFieldsToExcludeFromPurification.

Deprecated the `returnFormatted` parameter in `getNameAndEmail` and updated relevant code to align with the new method.