How to remove stuck persistent setting after upgrade

I have just upgraded my cluster from 5.6 to 6.1. I did a rolling upgrade as the documentation specified. It looks like a setting that I was using isn't available anymore in 6.1. That would've been fine, but now I can't even enable my shard allocation, so now my last node won't allocate its shards. Doing something as simple as this:

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
    "persistent" : {
        "cluster.routing.allocation.enable" : "all"
    }
}

results in this:

{
  "error" : {
    "root_cause" : [
      {
        "type" : "remote_transport_exception",
        "reason" : "[inoreader-es4][92.247.179.253:9300][cluster:admin/settings/update]"
      }
    ],
    "type" : "illegal_argument_exception",
    "reason" : "unknown setting [indices.store.throttle.max_bytes_per_sec] did you mean [indices.recovery.max_bytes_per_sec]?"
  },
  "status" : 400
}

No matter what setting I try to change I always get this error.
Yes, I did set indices.store.throttle.max_bytes_per_sec as persistent setting once in 5.x, and I'm OK with having to set it to a new name now, but how can I even remove it? It's not in elasticsearch.yml.

as i know this is delete in es 6

set:
"indices.store.throttle.max_bytes_per_sec": null
remove it.

I've tried that already. It raises the same error. In fact ANY setting that I try to PUT raises the same error unknown setting [indices.store.throttle.max_bytes_per_sec] did you mean [indices.recovery.max_bytes_per_sec]?. I can't seem to find a way to remove it via the APIs.

show your put curl..

@jacket can you try
PUT _cluster/settings { "persistent": { "indices.store.throttle.*": null } }?

I'm not sure why it doesn't let you set that specific setting to null, but try removing everything under throttle, see if that works.

it know in 6.x? or in 5.x ?
if 5.x use this.

as i know not use * use "indices.store.throttle.max_bytes_per_sec": null

How about using an empty string "" instead of null
Same result?

Yes, that should work in 5.x and 6.x.