SOA details not settable when using powerdns_zone

[c33s]

this issue is related to #43 and #45

currently the provider has still its problem, it can't handle soa records without manual intervention. even having the "add option soa_edit_api" #40 it conflicts with custom SOA records.

if i only define a zone, i don't have to manually set the soa record.

resource "powerdns_zone" "foobar" {
  name        = "example.net."
  kind        = "MASTER"
  soa_edit_api = "DEFAULT"
  nameservers = [...]
}

but i cannot configure all soa fields and will end up with an invalid soa record:

a.misconfigured.powerdns.server hostmaster.example.net 2020122102 10800 3600 604800 3600

if i add a custom soa recoard additionally to the zone

resource "powerdns_record" "foobar3" {
  zone    = "example.net."
  name    = "example.net."
  type    = "SOA"
  ttl     = 3600
  records = ["ns1.example.com. hostmaster.example.com. 2020122101 10800 3600 360000 300"]
}

it will work in the first run but as i add A records i will get conflicting SOA records.

can anyone use powerdns with this provider without manual intervention? are only docs missing or does it simply not work?

as @ion1 commented https://github.com/pan-net/terraform-provider-powerdns/issues/43#issuecomment-660361084 a special placeholder in the soa record like <auto> (@ion1 suggested 0) would help.

an alternative would be to allow to set all SOA data with the powerdns_zone.

today i also noticed that with the zone we set soa_edit_api which is for SOA-EDIT-DNSUPDATE and not SOA-EDIT as i asumed from #29 (which of course make sense, as it is the zone i set and not the server config)

just to list the values from the powerdns docs here:

https://doc.powerdns.com/authoritative/dnssec/operational.html#possible-soa-edit-values

• SOA-EDIT
  • INCREMENT-WEEKS
  • INCEPTION-EPOCH
  • INCEPTION-INCREMENT
  • EPOCH

https://doc.powerdns.com/authoritative/dnsupdate.html#soa-edit-dnsupdate-settings

• SOA-EDIT-DNSUPDATE
  • DEFAULT
  • INCREASE
  • EPOCH
  • SOA-EDIT
  • SOA-EDIT-INCREASE

it would really make sense to improve the docs here but to improve the docs it would be required that one of the implementing devs describe what is the right way for handling this.