Run unit tests without the Elasticsearch data load

[jrhoads]

Purpose

Let the unit suite run without loading the Elasticsearch dump, and run the heartbeat check only after that dump is indexed.

Approach

The heartbeat view is the unit test that talks to the live index. Move it into tests_integration, which runs after manage.py setup. Run tests_unit before that load. In CI, run tests_integration.tests_heartbeat after the load. Leave the HTTP integration modules and tests_functional commented out: they expect a full public corpus (specific ROR IDs and more than 50,000 records), and the CI test dump does not contain that. Skip the old v1 integration class, which still expects the removed response shape.

Key Modifications

• Remove HeartbeatViewTestCase from tests_unit and add it under tests_integration, checking GET /heartbeat against the indexed data.
• Run unit tests before manage.py setup in .github/workflows/run_tests.yml.
• After the dump is indexed, run rorapi.tests.tests_integration.tests_heartbeat.
• Skip tests_integration/tests.py (APITestCase) because it asserts the v1 name and country.country_code fields.

Important Technical Details

• Heartbeat returns 200 only when organizations-v2 exists. Without the dump, that test fails, which is why it cannot stay in the unit suite.
• The other unit tests mock Elasticsearch, so they do not need the dump.
• tests_v2, tests_search_v2, and tests_matching_v2 call the HTTP API and assert records that are not in the CI dump. Turning the whole package on failed those assertions. They stay commented, with that reason in the workflow.
• tests_functional stays disabled until its evaluation harness passes.

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)

Test plan

• CI tests_unit passes without the data load
• CI heartbeat integration test passes after manage.py setup

Reviewer, please remember our guidelines:

• Be humble in the language and feedback you give, ask don't tell.
• Consider using positive language as opposed to neutral when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
• Offer suggestions on how to improve code e.g. simplification or expanding clarity.
• Ensure you give reasons for the changes you are proposing.