Return global ttl when entity ttl is retrieved with entity cache enabled set to false

[aaronburtle]

Why make this change?

Closes #3148

What is this change?

Within the code paths for executing a REST request with the RuntimeCacheOptions enabled, we would attempt to get the entity cache ttl, however, if the entity had its cache options not enabled this would result in an exception, leading to a bad request returned to the user. However, the code path was already safeguarded by checking if we have entity cache enabled before executing a cache-based response, and so we did not need the exception when getting the entity cache ttl, and can safely return the global ttl here.

How was this tested?

A simple regression test is added that validates the new behavior.

Sample Request(s)

• Example REST and/or GraphQL request to demonstrate modifications
• Example of CLI usage to demonstrate modifications

[Copilot]

Pull request overview

Fixes a REST caching edge-case where global runtime caching is enabled but an entity has caching disabled/omitted, preventing requests from failing due to cache TTL/level lookups.

Changes:

• Update RuntimeConfig.GetEntityCacheEntryTtl() and GetEntityCacheEntryLevel() to return defaults when entity caching is disabled instead of throwing.
• Add a regression test covering the “runtime cache enabled + entity cache disabled/omitted” scenario.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Config/ObjectModel/RuntimeConfig.cs	Avoids throwing when cache TTL/level is requested for an entity with caching disabled by returning fallback defaults.
src/Service.Tests/Caching/CachingConfigProcessingTests.cs	Adds regression coverage ensuring TTL/level retrieval doesn’t throw when runtime cache is enabled but entity cache is disabled/omitted.

[Copilot]

GetEntityCacheEntryLevel returns EntityCacheLevel.L1L2 directly when entity caching is disabled. Prefer returning EntityCacheOptions.DEFAULT_LEVEL here to avoid duplicating the default value and keep this method consistent if the default changes in the future.

[JerryNixon]

Removing the old behavior

if (!entityConfig.IsCachingEnabled)
{
    throw new DataApiBuilderException(
        message: $"{entityName} does not have caching enabled.",
        statusCode: HttpStatusCode.BadRequest,
        subStatusCode: DataApiBuilderException.SubStatusCodes.NotSupported);
}

Now means all the internal calls need new gates to check if IsCachingEnabled. I can't tell if every code path added this, but it's important to note that these methods no longer throw and this behavior is drastically different.