remove append mode

Author: mapedraza

doc/admin.md

@@ -16,7 +16,6 @@
         -   [subservice](#subservice)
         -   [providerUrl](#providerurl)
         -   [iotaVersion](#iotaversion)
-        -   [appendMode](#appendmode)
         -   [dieOnUnexpectedError](#dieonunexpectederror)
         -   [singleConfigurationMode](#singleconfigurationmode)
         -   [timestamp](#timestamp)
@@ -350,12 +349,6 @@ URL to send in the Context Provider registration requests. Should represent the
 indicates the version of the IoTA that will be displayed in the about method (it should be filled automatically by each
 IoTA).
 
-#### `appendMode`
-
-if this flag is activated, the update requests to the Context Broker will be performed always with APPEND type, instead
-of the default UPDATE. This have implications in the use of attributes with Context Providers, so this flag should be
-used with care. This flag is overwritten by `autoprovision` flag in group or device provision.
-
 #### `dieOnUnexpectedError`
 
 if this flag is activated, the IoTAgent will not capture global exception, thus dying upon any unexpected error.
@@ -496,7 +489,6 @@ overrides.
 | IOTA_MONGO_SSL                       | `mongodb.ssl`                   |
 | IOTA_MONGO_EXTRAARGS                 | `mongodb.extraArgs`             |
 | IOTA_SINGLE_MODE                     | `singleConfigurationMode`       |
-| IOTA_APPEND_MODE                     | `appendMode`                    |
 | IOTA_POLLING_EXPIRATION              | `pollingExpiration`             |
 | IOTA_POLLING_DAEMON_FREQ             | `pollingDaemonFrequency`        |
 | IOTA_AUTOCAST                        | `autocast`                      |

doc/devel/northboundinteractions.md

@@ -155,9 +155,8 @@ As it can be seen in the example, the payload is a JSON Object with the followin
     with the information needed to identify the target entity `id` and `type` attributes. The `entities` attribute is an
     array, so a single update context batch operation can be used to update multiple devices
 
--   An `actionType` indicating the type of update: if this attribute has the value `"append"` the appropriate entity and
-    attributes will be created if the don't exist; if the value is `"update"`, an error will be thrown if the target
-    resources don't exist.
+-   An `actionType` indicating the type of update. It has the value `"append"` the appropriate entity and attributes
+    will be created if the don't exist.
 
 The equivalent **NGSI-LD** payload is associated to an update operation (PATCH `/ngsi-ld/v1/entities/<entity>/attrs/`).
 
@@ -600,20 +599,6 @@ It is worth mentioning that the Context Broker will reply with a 200 OK status c
 refer to transport protocol level errors, while the status codes inside of a payload give information about the
 application level protocol.
 
-The example shows an error updating an non-existent attribute (due to the use of UPDATE instead of APPEND).
-
-The following error payload is also valid in standard NGSI:
-
-```json
-{
-    "error": "NotFound",
-    "description": "The requested entity has not been found. Check type and id"
-}
-```
-
-Different kinds of errors can return their information in different formats, so NGSI implementations should check for
-the existence of both.
-
 ### Scenario 2: lazy attributes (happy path)
 
 Scenario 2 relies on the Context Provider mechanism of the Context Broker. For this scenario to work, the IoTAgent must