feat: Application module architecture and placeholder features (#70)

With this architecture, we have an extensible application module for which we can easily define new features and add them to application scores.

All this is driven by the ApplicationInterpret, who understands features and make sure they are "installed".

The drawback of this design is that we now have three different places to launch scores within Harmony : Maestro, Topology and Interpret. This is an architectural smell and I am not sure how to deal with it at the moment.

However, all these places where execution is performed make sense semantically : an ApplicationInterpret must understand ApplicationFeatures and can very well be responsible of them. Same goes for a Topology which provides features itself by composition (ex. K8sAnywhereTopology implements TenantManager) so it is natural for this very imp
lementation to know how to install itself.

Co-authored-by: Ian Letourneau <ian@noma.to>
Reviewed-on: NationTech/harmony#70
Co-authored-by: Jean-Gabriel Gill-Couture <jg@nationtech.io>
Co-committed-by: Jean-Gabriel Gill-Couture <jg@nationtech.io>

harmony/src/modules/application/features/monitoring.rs

@@ -0,0 +1,18 @@
+use async_trait::async_trait;
+use log::info;
+
+use crate::{
+    modules::application::ApplicationFeature,
+    topology::{HelmCommand, Topology},
+};
+
+#[derive(Debug, Default)]
+pub struct Monitoring {}
+
+#[async_trait]
+impl<T: Topology + HelmCommand + 'static> ApplicationFeature<T> for Monitoring {
+    async fn ensure_installed(&self, _topology: &T) -> Result<(), String> {
+        info!("Ensuring monitoring is available for application");
+        todo!("create and execute k8s prometheus score, depends on Will's work")
+    }
+}