o/c/configcore,o/ifacestate: check for presence of handler-service on startup

[olivercalder]

During snapd startup, if the "apparmor-prompting" flag is enabled but there is no snap with an interfaces-requests-control connection and an app app declared as a "handler-service", then record a warning that prompts will be auto-denied until a prompting client is installed.

Such a situation could arise if the user uninstalled the prompting client snap without disabling the "apparmor-prompting" feature flag, or if they disconnected the plug for the interfaces-requests-control interface.

There is a check for the presence of a handler-service client when one attempts to enable the "apparmor-prompting" feature flag in the first place: when enabling the flag, if there is no handler-service app present, or it cannot be successfully started, then the flag is left disabled. Before this commit, however, there were no subsequent checks for the presence of a handler-service, so the user would have no indication of why snaps may be blocking on syscalls or having syscalls denied. Now, we make this check again at snapd startup, but rather than disabling prompting, we instead simply record a warning to the user.

In a previous iteration of this PR, if no handler-service was connected during snapd startup, then prompting was treated as inactive until snapd was restarted. The implementation of that approach can be found here: dabea71

This work is tracked internally by https://warthogs.atlassian.net/browse/SNAPDENG-34245

[olivercalder]

The tests for interfacesRequestsControlHandlerServicePresent etc. need to be migrated from overlord/configstate/configcore, but there's some complexity around mocking. I'll take a look at this again tomorrow.

[codecov]

Codecov Report

Attention: Patch coverage is 67.39130% with 15 lines in your changes missing coverage. Please review.

Project coverage is 78.29%. Comparing base (24a0034) to head (4761cfb).
Report is 71 commits behind head on master.

Files with missing lines	Patch %	Lines
overlord/ifacestate/ifacestate.go	58.62%	8 Missing and 4 partials ⚠️
overlord/ifacestate/ifacemgr.go	81.25%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #14843      +/-   ##
==========================================
+ Coverage   78.20%   78.29%   +0.08%     
==========================================
  Files        1151     1154       +3     
  Lines      151396   152638    +1242     
==========================================
+ Hits       118402   119508    +1106     
- Misses      25662    25758      +96     
- Partials     7332     7372      +40     

Flag	Coverage Δ
unittests	78.29% <67.39%> (+0.08%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[olivercalder]

We don't want to treat prompting as inactive if there's no client, instead check for the presence of a client and record a warning if there's not one. So I need to rework this PR.

[olivercalder]

This PR has been reworked to record a notice rather than marking prompting as disabled, if there is no handler service connected during snapd StartUp.

[miguelpires]

lgtm, thank you

[miguelpires]

it's a nitpick but why not call this directly?

[olivercalder]

I want the function to be a method but I want to be able to mock the implementation as a function which can take a minimal InterfaceManager wrapper around a custom state. But in retrospect, I think I was trying to have it both ways: either the method itself should be mockable or the implementation should simply take a state.State instead of an InterfaceManager. Would you prefer the former?