DRAFT - Response Cache re-design for future releases

The global response cache and the LocalResponseCache filter are different components, however, the global depends on the local filter, which seems a bit confusing. On the other hand, having the global filter flag enabled and having the LocalResponseCache filter deactivated doesn't make sense. Also, this filter is intended for one Cache per Route, but because of the nature of a filter, the filter can be applied several times to the same route having multiple caches for a single route which can introduce glitches.

spring:
  cloud:
    gateway:
      filter:
       local-response-cache:
          enabled: true
      global-filter:
        local-response-cache:
          enabled: true
      routes:
        - id: route-1
          metadata:
            local-response-cache:
              size: 1MB
              time-to-live: 30m
          ...

The request passes through the filters as

*LocalResponseCache (if present in the route) -> Global (response cache)

A new approach is to have one flag for activating a global response cache, that can be customised for specific routes using metadata section.

spring:
  cloud:
    gateway:
      global-filter:
        local-response-cache:
          enabled: true
      routes:
        - id: route-1
          metadata:
            local-response-cache:
              size: 1MB
              time-to-live: 30m
          ...

Start by reviewing the global response cache and the LocalResponseCache filter, then trace how both are activated and applied to routes. Compare that behavior with the proposed single global flag and route-level metadata configuration. Done means one cache path is used per route, with global activation and route customization behaving consistently.