Feature reset API should fail fast when action.destructive_requires_name is true

[benwtrent]

Elasticsearch version (bin/elasticsearch --version):
master

Description of the problem including expected versus actual behavior:
Calling the feature reset API with action.destructive_requires_name: true results in the API
returning as if no failures occurred, but no reset actually took place
Steps to reproduce:

1. Set action.destructive_requires_name to true
2. Have some system indices (possibly .ml-* related ones)
3. Call the reset feature API
4. Notice no failure returned, but reset feature call failed to delete anything

I think to fix this, the API call should blow up when this setting is false to indicate failure.

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[williamrandolph]

My intention was for the reset to succeed no matter the value of that setting. I'll see if I can figure out what's going on.

[williamrandolph]

After some investigation:

1. I agree that the reset API should fail fast and will put out a PR to this effect.
2. The specific failure has to do with not resolving associated index names before issuing the delete command. We resolve managed system indexes and delete them by name, and could do the same for associated indices, but I can file another issue to fix that problem.