While looking at elastic#3703, it looks like the usage of 'read_only' is a bit confusing.

The documentation stipulates:
> index.blocks.read_only
> Set to true to have the index read only, false to allow writes and metadata changes.

Actually, it blocks all write operations (creating, indexing or deleting a document) but also all read/write operations on index metadata. This can lead to confusion because subsequent 'indices exists' requests will return an undocumented 403 Forbidden response code where one could expect a 200 OK (as reported in elastic#3703). Same for 'type exists' and 'alias exists' requests.

Similar issues have been reported:
- _status elastic#2833 (deprecated in 1.2.0)
- _stats elastic#5876
- /_cat/indices elastic#5855

But several API calls returns a 403 when at least one index of the cluster has 'index.blocks.read_only' set to true:

DELETE /_all

POST /library/book/1
{
  "title": "Elasticsearch: the definitive guide"
}

POST /movies/dvd/1
{
  "title": "Elasticsearch: the movie"
}

PUT /library/_settings
{
  "index": {
    "blocks.read_only": true
  }
}

The following calls will return 403 / "ClusterBlockException[blocked by: [FORBIDDEN/5/index read-only (api)];]":

HEAD /library
HEAD /library/book
HEAD /_all/dvd

GET /library/_settings
GET /library/_mappings
GET /library/_warmers
GET /library/_aliases

GET /_settings
GET /_aliases
GET /_mappings
GET /_cat/indices

I agree to @imotov's comment (see elastic#5876 (comment)) and I think we should split the METADATA blocks in METADATA_READ & METADATA_WRITE blocks. This way the 'read_only' setting will block all write operations and metadata updates but the metadata will still be available.

This is a first step in this way, closes elastic#3703