Improve extra key handling

[mcalmer]

What does this PR change?

Adding new extratag keys during reposync can fail with

duplicate key value violates unique constraint "rhn_pkg_extra_tag_key_idx"
DETAIL:  Key (name)=(Cnf-Extra-Commands) already exists.

This result in failed imports of a bunch of packages. To improve the creation of new keys, this PR declare lookup and insert functions and make use of it in the import code.

Second case found while inserting into rhnPackageKey.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes

• DONE

Test coverage

• No tests: manual

• DONE

Links

Fixes #3040
Tracks https://github.com/SUSE/spacewalk/pull/13545

• DONE

Changelogs

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_oracle"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

[moio]

@mcalmer while I see that the patch here works for addressing the issue, I think a better approach could be use INSERT INTO... ON CONFLICT DO NOTHING. That has the advantage of allowing batches of insertions, which is faster than individual ("per object") calls to the lookup stored procedures. That would also allow not to add another "nested insert SP" hack.

This is the pattern I have been using during the reposync speedup, and would recommend keeping it in new code as well.

You can see an example of such patch here:

82ee013

You can see several other instances of this pattern in backlog.py by grepping for ON CONFLICT DO NOTHING.

I hope I am not missing any important aspect that would prevent the above approach from working here - in that case just let me know.

[moio]

LGTM