Refactor load_file tests

[dimberman]

Description
As a step towards "maturing" the astro DAG authoring project, we must rewrite our tests to ensure that every integration test runs against every database.

This step will simultaneously reduce the number of tests we need to maintain, make testing much simpler as we add new databases, and will make a future refactor much simpler as we can ensure proper coverage.

To do this, we will take advantage of two features in pytest, fixtures and parameterize.

For this ticket, we will update the append function.

Acceptance criteria
Have a single test file validating append across all databases.

1. Integration tests should be marked with pytest.marker.integration:

• Each test should work across all databases
• Validating both Table and TempTable as inputs
• Use test_utils.run_dag
• Use PyTest fixtures and parameterize to have a single main test that will validate transform across multiple databases

The tests should validate these scenarios:

1. loading against all formats (csv, parquet, avro, etc.)
2. loading to a temp_table or named table
3. loading to default schema and to named schema

[tatiana]

@dimberman the description mentions append, but the title says load_file. Which one is this?

Also, I think it is important to mention that load_file was the first place where we started introducing the new style of integration tests.

These lines were the first place where we adopted the new integration tests approach:
https://github.com/astro-projects/astro/blob/main/tests/operators/test_agnostic_load_file.py#L532-L801

What is missing, IMPOV is to refactor these lines:
https://github.com/astro-projects/astro/blob/a83308a32f513a1e4049bc6dd98730c4e12de9f5/tests/operators/test_agnostic_load_file.py#L68-L529

Finally, I don't think we should be aiming to have a single test function per operator. I'd vote for us to have three independent tests than this type of fixture:
https://github.com/astro-projects/astro/blob/main/tests/operators/test_agnostic_merge.py#L47-L79

We are at risk of overusing fixtures, which can compromise the readability of the tests.

[utkarsharma2]

@dimberman, I think I can partially work on this, refactoring testcases which are having conflicting table names.