Filter Realms processed by acl-config

[ryanrath]

Co-authored-by: @plessbd

Description

• acl-config: Utilizes the [resources|resource_types].json files to determine
  which realms are enabled. A realm is considered enabled if there is at
  least one resource w/ a resource_type that has a matching realm record.
• ConfigFilesMigration: Makes sure that we update the existing
  resource_types.json file from resource_type_id -> resource_type.
• etl.d/resource_types.json: We're manually inserting the 'unknown' resource
  now as opposed to including it in resources.json. This allows us to utilize
  -1 as the id. To account for that, a new action has been added to
  the ingest-resource-types pipeline.
• xdmod-migration-8_1_2-8_5_0.json: We need to make sure that the foreign
  key constraint on resources is updated.
• etl_action_defs.d/common/hpcdb/resources.json: Just updating the default
  value to be in line with the changes made in etl.d/resource_types.json.
• unknown_resource_type.sql: The manual insertion of the unknown resource
  type.
• etl_tables.d/.../resource-types.json: Adding the type_abbr column so that
  we can translate from type_abbr -> type_id and vice versa.
• etl_tables.d/...resources.json: Updated the fk_resource_res_type fk to
  include on_delete|on_update clauses. This change allows the DB to take care
  of keeping resource_types -> resources in sync.
• configuration/resource_types.json: Removing the Unknown resource_type as
  it's now manually inserted.
• roles.json: The query_descripters / summary_charts for default were
  previously removed. We are adding them back in here.

Motivation and Context

We're moving towards allowing XDMoD to be installed with any combination of Realms as opposed to assuming that the Jobs realm is present. Specifically, this PR updates acl-config to utilize resource_types.json and resources.json to determine which realms are actually valid / enabled for the current installation. It will then only process the configuration data for those realms.

Tests performed

• All automated tests were run in both a fresh install & upgrade scenario.
• Manual spot testing was also conducted to ensure there were no knock on effects from the changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project as found in the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[plessbd]

as an addendum to the motivation.
this also allows an administrator to change the configuration files and it be handled by rpm when a change is made so that we do not have to migrate things like the realms files.