Issue/2965 - Documentation does not reflect latest changes for datafrom for IBM Secret Manager (#3010)

* 2963 - removed duplicated annotations

Signed-off-by: Benjamin Walterscheid <benjamin.walterscheid@de.ibm.com>

* 2963 - updated documentation to use kv secret types with v1beta1 apiVersion

Signed-off-by: Benjamin Walterscheid <benjamin.walterscheid@de.ibm.com>

* 2963 - minor yaml corrections

Signed-off-by: Benjamin Walterscheid <benjamin.walterscheid@de.ibm.com>

* added some example for v2 literal templating (#3007)

Signed-off-by: Robert Paschedag <robert.paschedag@sap.com>
Co-authored-by: Robert Paschedag <robert.paschedag@sap.com>
Signed-off-by: Benjamin Walterscheid <benjamin.walterscheid@de.ibm.com>

---------

Signed-off-by: Benjamin Walterscheid <benjamin.walterscheid@de.ibm.com>
Signed-off-by: Robert Paschedag <robert.paschedag@sap.com>
Co-authored-by: Benjamin Walterscheid <benjamin.walterscheid@de.ibm.com>
Co-authored-by: Robert Paschedag <robert.paschedag@web.de>
Co-authored-by: Robert Paschedag <robert.paschedag@sap.com>

docs/provider/ibm-secrets-manager.md

@@ -146,7 +146,9 @@ The behavior for the different secret types is as following:
 
 #### kv
 * An optional `property` field can be set to `remoteRef` to select requested key from the KV secret. If not set, the entire secret will be returned
-* `dataFrom` retrieves a string from secrets manager and tries to parse it as JSON object setting the key:values pairs in resulting Kubernetes secret if successful
+* `dataFrom` retrieves a string from secrets manager and tries to parse it as JSON object setting the key:values pairs in resulting Kubernetes secret if successful. It could be either used with the methods
+  * `Extract` to extract multiple key/value pairs from one secret (with optional `property` field being supported as well)
+  * `Find` to find secrets based on tags or regular expressions and allows finding multiple external secrets and map them into a single Kubernetes secret
 
 ```json
 {
@@ -173,10 +175,25 @@ data:
 - secretKey: key_all
   remoteRef:
     key: 'kv/aaaaa-bbbb-cccc-dddd-eeeeee'
+```
 
+```yaml
 dataFrom:
-  - key: 'kv/aaaaa-bbbb-cccc-dddd-eeeeee'
-    property: 'key3'
+  - extract:
+    key: 'kv/fffff-gggg-iiii-dddd-eeeeee' #mandatory
+    decodingStrategy: Base64 #optional
+
+```
+
+```yaml
+dataFrom:
+  - find:
+      name:  #matches any secret name ending in foo-bar
+        regexp: "key" #assumption that secrets are stored like /comp/key1, key2/trigger, and comp/trigger/keygen within the secret manager
+  - find:
+      tags: #matches any secrets with the following metadata labels
+        environment: "dev"
+        application: "BFF"
 ```
 
 results in
@@ -188,9 +205,22 @@ data:
   special_key: ... #special-content
   key_all: ... #{"key1":"val1","key2":"val2", ..."special.key":"special-content"}
 
-  # secrets from dataFrom
-  keyA: ... #valA
-  keyB: ... #valB
+  # secrets from dataFrom with extract method
+  keyA: ... #1st key-value pair from JSON object
+  keyB: ... #2nd key-value pair from JSON object
+  keyC: ... #3rd key-value pair from JSON object
+
+  # secrets from dataFrom with find regex method
+  _comp_key1: ... #secret value for /comp/key1
+  key2_trigger: ... #secret value for key2/trigger
+  _comp_trigger_keygen: ... #secret value for comp/trigger/keygen
+
+  # secrets from dataFrom with find tags method
+  bffA: ...
+  bffB: ...
+  bffC: ...
+
+
 ```
 
 ### Creating external secret
@@ -223,7 +253,7 @@ kubectl get secret secret-to-be-created -n <namespace> | -o jsonpath='{.data.tes
 ### Populating the Kubernetes secret with metadata from IBM Secrets Manager Provider
 ESO can add metadata while creating or updating a Kubernetes secret to be reflected in its labels or annotations. The metadata could be any of the fields that are supported and returned in the response by IBM Secrets Manager.
 
-In order for the user to opt-in to adding metadata to secret, an existing optional field `spec.dataFrom.extract.metadataPolicy` can be be set to `Fetch`, its default value being `None`. In addition to this, templating provided be ESO can be leveraged to specify the key-value pairs of the resultant secrets' labels and annotation.
+In order for the user to opt in to adding metadata to secret, an existing optional field `spec.dataFrom.extract.metadataPolicy` can be set to `Fetch`, its default value being `None`. In addition to this, templating provided be ESO can be leveraged to specify the key-value pairs of the resultant secrets' labels and annotation.
 
 In order for the required metadata to be populated in the Kubernetes secret, combination of below should be provided in the External Secrets resource:
 1. The required metadata should be specified under `template.metadata.labels` or `template.metadata.annotations`.
@@ -246,9 +276,8 @@ kind: Secret
 metadata:
   annotations:
     reconcile.external-secrets.io/data-hash: 02217008d13ed228e75cf6d26fe74324
-  creationTimestamp: "2023-05-04T08:41:24Z"
-  annotations:
-    secret_id: 1234
+    creationTimestamp: "2023-05-04T08:41:24Z"
+    secret_id: "1234"
     updated_at: 2023-05-04T08:57:19Z
   name: database-credentials
   namespace: external-secrets
@@ -259,7 +288,7 @@ metadata:
     kind: ExternalSecret
     name: database-credentials
     uid: c2a018e7-1ac3-421b-bd3b-d9497204f843
-  resourceVersion: "1803567"
-  uid: f5dff604-611b-4d41-9d65-b860c61a0b8d
+  #resourceVersion: "1803567" #immutable for a user
+  #uid: f5dff604-611b-4d41-9d65-b860c61a0b8d #immutable for a user
 type: Opaque
 ```