Merging to release-5-lts: TT-9158 prefetch org expiry when loading th…

…e apis (#5798) (#6014)

TT-9158 prefetch org expiry when loading the apis (#5798)

<!-- Provide a general summary of your changes in the Title above -->

## Description

Previously, when operating in a slave configuration, the Tyk Gateway
fetched session expiry information from the master layer the first time
an API was accessed for a given organization. This approach led to a
significant issue: if the MDCB connection was lost, the next API
consumption attempt would incur a long response time. This delay,
typically around 30 seconds, was caused by the gateway waiting for the
session fetching operation to time out, as it tried to communicate with
the now-inaccessible master layer.

Implemented Solution: To mitigate this issue, the PR introduces a
proactive fetching strategy. Now, the gateway fetches the session expiry
information beforehand, while there is an active connection to MDCB. By
doing so, it ensures that this data is already available locally in the
event of an MDCB disconnection.

Outcome: This change significantly improves the API response time under
MDCB disconnection scenarios. It eliminates the need for the gateway to
wait for a timeout when attempting to fetch session information from the
master layer, thus avoiding the previous 30-second delay. This
optimization enhances the resilience and efficiency of the Tyk Gateway
in distributed environments.

This option comes to complement the config option
`slave_options.call_timeout` which defaults to 30sec, users can set a
lower value.

## Related Issue

TT-9158

## Motivation and Context

<!-- Why is this change required? What problem does it solve? -->

## How This Has Been Tested

<!-- Please describe in detail how you tested your changes -->
<!-- Include details of your testing environment, and the tests -->
<!-- you ran to see how your change affects other areas of the code,
etc. -->
<!-- This information is helpful for reviewers and QA. -->

## Screenshots (if appropriate)

## Types of changes

<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test
coverage to functionality)

## Checklist

<!-- Go over all the following points, and put an `x` in all the boxes
that apply -->
<!-- If there are no documentation updates required, mark the item as
checked. -->
<!-- Raise up any additional concerns not covered by the checklist. -->

- [ ] I ensured that the documentation is up to date
- [ ] I explained why this PR updates go.mod in detail with reasoning
why it's required
- [ ] I would like a code coverage CI quality gate exception and have
explained why

---------

Co-authored-by: Sredny M <[email protected]>