Add delete flag to external-resources

[lechuk47]

External resources deletion will work with the delete: true attribute at the resource level.

externalResources:
- provider: aws
  provisioner:
    $ref: /aws/app-sre-stage/account.yml
  resources:
  - provider: rds
    managed_by_erv2: true
    identifier: erv2-tests
    defaults: /terraform/resources/erv2-tests/rds/pg14-defaults.yml
    parameter_group: /terraform/resources/erv2-tests/rds/pg14-default-pg.yml
    delete: true # <-- This resource will get deleted.

Why:

• This is a well-established pattern to delete resources in app-interface (saas targets, namespaces, etc).
• TF-Resources deletion_approvals are meant to avoid non-wanted resource deletions in case resource specs are removed from app-interface. Requiring a delete: true attribute accomplishes the same objective.
• Tenants don't need to care about secondary terraform objects to delete, they just want to remove the resource.
• This change introduces the "feature" of abandoning resources.

Schema update: app-sre/qontract-schemas#683

[hemslo]

why do we need to exclude those fields? There is a similar method serialize_input in ExternalResource, and to serialize json, can directly call resource.json( instead of resource.dict( then json.dumps

[lechuk47]

• These fields are not expected in the module input. Since the overrides parameter doesn't have a schema, all the overridden parameters are passed to the terraform object directly (the same way as terraform-resources). So all parameters not expected in the input shall be removed.

• I changed the call to resource.json() and removed the method in ExternalResource (this was used in an old implementation when the INPUT was passed as an env var)

[hemslo]

Is there a way to ignore unexpected input or define a clear mapping? Otherwise we have to remember edit this part whenever we put new fields in data

[lechuk47]

I cannot think of anything to do that as we want the ability to add additional fields in the overrides.
There should not be a lot of changes here since only "logical" parameters need to be introduced.
I agree though, I'll try to overcome this or at least have a way to detect it with a test or something.

[hemslo]

LGTM!