advanced-routing units go into blocked status even if apply-changes action is run

[Paul Goins]

This is related to https://bugs.launchpad.net/charm-advanced-routing/+bug/1871856, but slightly different.

From what I've seen, even if the apply-changes action is run, the units ultimately revert to a blocked state, claiming that there are "Changes pending via apply-changes action". This makes it impossible to tell via juju status which units have had routes applied versus which have not, and increases the likelihood of not running the action when it really is needed.

This was encounterd on cs:advanced-routing-2, however a (quick) code review seems to indicate this likely occurs with cs:advanced-routing-4, the latest version at the time of writing, as well.

[Paul Goins (vultaire)]

I traced this down.

We thought we were saving the flag, but we neglected to explicitly call unitdata.kv().flush(). It appears this is generally handled for us in hook environments (e.g. charms.reactive), but during actions we need to handle it ourselves.

As an example, look at charm-vault: it explicitly calls out the need to do this in the case of successfully executing an action. Reference: https://git.launchpad.net/vault-charm/tree/src/actions/actions.py?id=fe95a83afb55733c01526e973c7f190632e30547#n230

[Paul Goins (vultaire)]

Merge request, with an additional small improvement re: action error output: https://code.launchpad.net/~vultaire/charm-advanced-routing/+git/charm-advanced-routing/+merge/404622