feat(metrics): Add failure_reason label to ingress_controller_configuration_push_count metric

[czeslavo]

What this PR does / why we need it:

• adds failure_reason label to the already existing ingress_controller_configuration_push_count metric which is reported every time configuration is pushed to the data plane
• the label enables distinguishing config conflicts reasons: conflict, network, other.

Which issue this PR fixes:

Part of #2484

Special notes for your reviewer:

I was able to trigger configuration conflicts by adding consumers violating the unique username constraint. Admin API was responding with HTTP code 409. I'm leveraging this, although it's not documented in Admin API's OpenAPI definitions.

In general, it's hard to rely on deck to return any specific error therefore some error heuristics were needed.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[rainest]

How does this behave with these failures under database mode? Initial read suggests this will never mark a conflict with that, since it'll get back some sort of deck failure instead of any underlying go-kong failures.

We may not really be able to do anything yet given that the deck syncer doesn't always have the most useful errors, but a brief read indicates that we do get back an error array that we can walk to see if any are conflicts.

[pmalek]

Please resolve the conflicts

[czeslavo]

How does this behave with these failures under database mode? Initial read suggests this will never mark a conflict with that, since it'll get back some sort of deck failure instead of any underlying go-kong failures.

We may not really be able to do anything yet given that the deck syncer doesn't always have the most useful errors, but a brief read indicates that we do get back an error array that we can walk to see if any are conflicts.

I've tested that with Postgres mode and you were right, in case of KongConsumer username conflict, the failure comes from deck's state.Get or dump.Get which would have been missed without some additional heuristics: 2fbcb50

I extended that with detecting network errors specifically as well as it was cheap enough.

[rainest]

Moved changelog back to 2.7 with some minor edits. It's still stuck as I try and wait for E2E tests to slowly reveal if they're no longer dying due to environment failures. We already have a minor bump and this is pretty innocuous, so it may as well go out.

deck/format string changes look addressed, so 👍