GET {db}/_index endpoint response does not reflect index deletion

[NOTE]: # ( ^^ Provide a general summary of the issue in the title above. ^^ )

## Description

[NOTE]: # ( Describe the problem you're encountering. )
[TIP]: # ( Do NOT give us access or passwords to your actual CouchDB! )
In our pipeline endpoint `GET /{db}/_index ` sometimes does not reflect the ddoc deletion with endpoint `DELETE/{db}/_index/_design/{ddoc}/{type}/{index}`.

Locally I cannot reproduce the problem, it happens in the pipeline, when multiple database creation/deletion occurs parallelly.

## Steps to Reproduce

[NOTE]: # ( Include commands to reproduce, if possible. curl is preferred. )
Here is the full scenario:

1. Create DB with unique name
2. Create index01
3. List indexes with `GET {db}/_index`(index01 is listed)
4. Delete index01 with `DELETE/{db}/_index/_design/{ddoc}/{type}/{index}`
5. List indexes with `GET {db}/_index` (index01 is still listed)

## Expected Behaviour

[NOTE]: # ( Tell us what you expected to happen. )
At step 5. the `GET {db}/_index` request should not include the deleted index field.

## Your Environment

[TIP]: # ( Include as many relevant details about your environment as possible. )
[TIP]: # ( You can paste the output of curl http://YOUR-COUCHDB:5984/ here. )

* CouchDB version used: 3.0.0-83bdcf6
* Browser name and version:
* Operating system and version: MacOS

## Additional Context

[TIP]: # ( Add any other context about the problem here. )
According to the discussion on a support channel the bug is that listing the existing indexes only queries an internal cache not the database itself.
It is an open question whether the deleted index ever got removed from the cache, if there is no other database changes.

Start by reproducing the listed create, index, delete, and list sequence while multiple databases are created or deleted in parallel. Investigate the internal cache used by GET /{db}/_index and compare it with DELETE /{db}/_index/_design/{ddoc}/{type}/{index}; done means the deleted index is absent from the subsequent listing.

Written by the indexing model from the issue text.