Branch/Environment/Version

• Branch/Version: Release / Tyk 5.10
• Environment: On-prem - Kubernetes cluster. OSS Helm Charts and latest Tyk 5.10 but the same in 5.9

Describe the bug
The classic API definitions are loaded from file-based directory /tyk-gateway/apps BEFORE the OAS definitions and overrides the "x-tyk-api-gateway" section in case f.e. if you change "listenPath". Other changes to f.e. server section are taken correctly from OAS.

Reproduction steps

Steps to reproduce the behavior:

1. Add new OAS via api http://:/tyk/apis/oas remember API-ID in response
2. Listenpath is /echo
3. Reload api defintion with /tyk/reload/?block=true
4. Check via control api /tyk/apis/oas/ and see new OAS with /echo
5. Same for api definitions. Check via control api /tyk/apis/ and see classic API defintion with /echo
6. Go to file directory ../tyk-gateway/apps change in file -oas.json listenPath to /echo2
7. Go to file directory ../tyk-gateway/apps change in file .json listenPath to /echo3
8. Reload api definition with /tyk/reload/?block=true
9. Check OAS definition /tyk/apis/oas/ and see /echo3
10. Check classic api defintion /tyk/apis/ and see /echo3

Actual behavior

It looks like the reload correctly take the changes from file directory and apply as new api defintions. But the classic api definition wins over the OES change.

Expected behavior
Since I originally came from the OES and this is my "Truth" I expect that these changes wins over classic definitions and are synchronized only in the background processes.

In the example I would expect /echo2 as change over /echo3.

Additionally the classic api definition file should be re-generated in this case. So that this also take /echo2.

Screenshots/Video
no

Logs (debug mode or log file):
no

Configuration (tyk config file):
Default tyk 5.10 or default tyk 5.9

Additional context
no