i/apparmor: add missing expansion for s-u-n template (#13853)

This fixes access to /etc/apparmor.d/tunables when running from snapd snap.
When snapd snap re-executes, and uses apparmor_parser from snapd snap (those
are separate conditions), then it re-directs the parser away from host
/etc/apparmor.d and we have special code to load tunables from the host anyway.
Those tunables are themselves conditional on the conditional include syntax
that may or may not be supported by apparmor (otherwise the would be explicitly
spelled out in the template, and not dynamically expanded with custom logic).

The problem was introduced along with patch
b98e4af (i/apparmor: support for home.d
tunables from /etc/ (#13118)), as the case for snap-update-ns was missed, and
the default expansion is an empty string.

Regression-testing this requires that we re-package snapd snap, so the test
will come in with a separate patch as it requires somewhat more effort to
behave correctly.

This issue was identified by Maciej Borzecki.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

interfaces/apparmor/backend.go

@@ -655,6 +655,16 @@ func addUpdateNSProfile(snapInfo *snap.Info, snippets string, content map[string
 				snippets += strings.Replace(apparmor_sandbox.OverlayRootSnippet, "###UPPERDIR###", overlayRoot, -1)
 			}
 			return snippets
+		case "###INCLUDE_SYSTEM_TUNABLES_HOME_D_WITH_VENDORED_APPARMOR###":
+			// XXX: refactor this so that we don't have to duplicate this part.
+			// TODO: rewrite this whole mess with go templates.
+			features, _ := parserFeatures()
+			if strutil.ListContains(features, "snapd-internal") {
+				return `#include if exists "/etc/apparmor.d/tunables/home.d"`
+			}
+			return ""
+		default:
+			// TODO: Warn that an invalid pattern is being used.
 		}
 		return ""
 	})