Soft design doc updates (without recomputing the views)

## Summary

The idea is to be able to update a design document without invalidating the existing index.

## Desired Behaviour

When updating a design document, make it possible that the new index uses the existing one as a starting point.

## Possible Solution

The user can specify `keep_index=true` as a query parameter when changing the design document with `PUT /{db}/_design/{ddoc}`

Internally, copy or rename the existing index file (I'm not sure if that would work out of the box)

## Additional context

On large database (Terabytes) updating an index with a custom JavaScript map function takes a very long time (days).

Many times it would be fine to update the view without recomputing the full index. For example we are often updating the view to process a new type of data that isn't already present in the database: this new type of data will enter the database when we roll out a feature to production.

In that case, we could update the view without recomputing the index on existing data: we know for a fact that the update has no impact on existing data. It would save days of delays to release the new feature.

In another instance, the view had a little bug. Being able to deploy a "hot fix" so new documents are not impacted by the bug would be incredibly helpful. Having to tell users to wait a few days for the fix isn't great.

Start with the PUT /{db}/_design/{ddoc} design-document update path and trace how its existing view index is invalidated. Determine how a keep_index=true request could reuse the current index while allowing new documents to use the updated view, and verify that ordinary updates still recompute indexes when required.

Written by the indexing model from the issue text.