Fix bug where ccompat and core api would report different compatibility mode values

[snophey]

Hi everyone. This PR attempts to address a bug that we have recently found. The issue is the following: in various situations the ccompat/v7 and the core/v2 APIs may return different values when the user queries the global compatibility level setting. To reproduce this issue:

1. Configure default global compatibility level by setting the REGISTRY_RULES_GLOBAL_COMPATIBILITY environment variable to BACKWARD
2. Now getting the compatibility level by querying /apis/ccompat/v7/config returns NONE while GET'ing corresponding core-v2 API endpoint (/apis/registry/v2/admin/rules/COMPATIBILITY) returns BACKWARD. Here, I would have expected the ccompat API to also consult the global rule and return BACKWARD, but this is not the case.
3. Set compatibility to NONE using the PUT /apis/registry/v2/admin/rules/COMPATIBILITY endpoint.
4. Observe that the reported compatibility is NONE for both APIs. This works fine.
5. Now set compatibility to NONE using the /apis/ccompat/v7/config endpoint
6. Now querying for compatibility via /apis/registry/v2/admin/rules/COMPATIBILITY returns BACKWARD while doing the same via the confluent API returns NONE. Here, the API call from step 5. simply deletes the compatibility rule, which makes the core API default to the REGISTRY_RULES_GLOBAL_COMPATIBILITY value, which is not correct IMO.

[apicurio-bot]

Thank you for creating a pull request!

Pinging @jsenko to respond or triage.

[EricWittmann]

Thanks @snophey ! We're just in the middle of finalizing everything for the 3.0.0 release, but we'll get this merged soon and then we'll port it to 3.x.