config-changed won't use updated data in error state, even when bad data is the reason it's there.

[Peter Petrakis]

This is trivially illustrated with the opengrok charm

$ juju deploy opengrok

<02:20:36>sprint-juju$ cat deploy.yaml
# vim:ts=2:sw=2:et:ft=yaml:
opengrok:
    og_content: '{
      "repos":[
        {
          "url" : "lp:juju",
          "alias" : "juju"
        }
       ]
    }'

We know this works, and is provided in the source tree as an example. Now I introduce a syntax error, adding
a ',' after the inner braces, JSON is expecting another array element and will fail to parse this code.

<02:24:01>sprint-juju$ cat deploy-broken.yaml
# vim:ts=2:sw=2:et:ft=yaml:
opengrok:
    og_content: '{
      "repos":[
        {
          "url" : "lp:juju",
          "alias" : "juju"
        },
       ]
    }'

$ juju set opengrok --config deploy-broken.yaml
$ juju status
...
    units:
      opengrok/0:
        agent-state: configure-error
        machine: 1

OK. Now I go through the debug-hooks && resolved -r incantation to get a shell to
"fix" this.

Clearly the data is broken so I try to update the data.

$ juju set opengrok --config deploy.yaml

Now in the context of the hook:
root@juju-canonistack-instance-1:/var/lib/juju/units/opengrok-0/charm# config-get og_content
{ "repos":[ { "url" : "lp:juju", "alias" : "juju" }, ] }

I could run hooks/config-changed into infinity, it's still working on the same garbage data that
initiated the fault and doesn't acknowledge the perfectly good data I just provided to remedy
the situation.

Here's the baffling part, I can use zooinspector to reach my bootstrap node and inspect the
data; under services/service-0000000000/config, *that* has the correct data, which means the
deployed charm is caching the previous value for some unknown reason. See attached screenshot.

Even weirder, juju status is now running! How is a user supposed to recover from a GIGO
scenario without major surgery?