[RFE] RFC 2317 support in Neutron with designate provider

proposal: RFC 2317 support in Neutron with designate provider
============================================================

Discussion
----------

**Summary : Add four settings `ipv4_ptr_zone`, `ipv4_ptr_record_template`, `ipv6_ptr_zone` and`ìpv6_ptr_record_template` in various contexts to allow for custom DNS zone selection and resource record generation in case of unusual DNS PTR zones.**

**Rationale:** The creation of PTR DNS zones for non byte-delimited subnets is not possible in OpenStack, it is therefore impossible to manage PTR records in case of a classless in-addr delegation, as described in RFC 2317.

In those situations, one can be given a delegation of a reverse zone with an unusual name, for instance 0-25.2.0.192.in-addr.arpa (when assigned the 192.0.2.0/25 prefix). This scheme is based on the fact that a DNS record for reverse resolution can be a CNAME to another record. This proposal adds a generic mechanism to properly handle such cases.

**Security considerations:** Giving users the ability to make neutron create new arbitrary zones in designate by updating PTR zone settings may pose a security risk. It would be preferable to limit the ability to update these settings to administrators only.

Proposed changes
----------------

Add a `ipv4_ptr_zone` setting to define a PTR zone name, and a `ipv4_ptr_record_template` setting to define the record name template. The template can use placeholders which are replaced with the n-th byte or nibble of the IP address. `%s(octetN)s` is a candidate and is already a notation used in Designate[1].

#### Use cases

Configuration for subnet 192.0.2.0/25 would be as follow:

```
ipv4_ptr_zone = "0-25.2.0.192.in-addr.arpa"
ipv4_ptr_record_template = "%(octet3)s"
```

Which would lead to this zone file:

```
$ORIGIN 0-25.2.0.192.in-addr.arpa

1 IN PTR reverse-1.example.
2 IN PTR reverse-2.example.
# [...]
127 IN PTR reverse-127.example.
```

Assuming that the parent zone has an accurate configuration, such as:

```
$ORIGIN 2.0.192.in-addr.arpa.

0-25 IN NS designate.os.example.
1 IN CNAME 1.0-25
2 IN CNAME 2.0-25
# [...]
127 IN CNAME 127.0-25
```

Configuration for the subnet `192.168.0.0/16` would look like:

```
ipv4_ptr_zone = "168.192.in-addr.arpa"
ipv4_ptr_record_template = "%(octet3)s.%(octet2)s"
```

Same logic for `172.16.0.0/12`:

```
ipv4_ptr_zone = "16/12.172.in-addr.arpa"
ipv4_ptr_record_template = "%(octet3)s.%(octet2)s.%(octet1)s"
```

When absent, the old behavior of `ipv4_ptr_zone_prefix_size` or `ipv6_ptr_zone_prefix_size` is kept.

### First step: global Neutron configuration

The behavior described above is configured with settings in the global neutron configuration file.

Raise an error in case of invalid setting configuration:
* `ipv4_ptr_zone_prefix_size` is set and either `ipv4_ptr_zone` or `ipv4_ptr_record_template` is set.
* `ipv4_ptr_zone` is set and `ipv4_ptr_record_template` is not set.
* `ipv4_ptr_zone` is not set and `ipv4_ptr_record_template` is set.
* The same applies for IPv6 settings.

### Second step: per-IPAllocationPool configuration

Global settings could be overwritten for each `IPAllocationPool`; however, it would require an update of both `IPAllocationPool` and `IPAllocation` models (in `neutron/db/models_v2.py`), as `IPAllocation` would need to keep track of `IPAllocationPool` rDNS settings.

Theses settings could be stored in the `IPAllocationPool` model:

```python
class IPAllocationPool(model_base.BASEV2, model_base.HasId):
    # [snip]
    ptr_zone = sa.Column(sa.String(255), nullable=True)
    ptr_record_template = sa.Column(sa.String(255), nullable=True)
```

A reference to the originating `IPAllocationPool` could be kept into the `IPAllocation` model in order to retrieve the rDNS settings:

```python
class IPAllocation(model_base.BASEV2):
    # [snip]
    ip_allocation_pool_id = sa.Column(sa.String(64), nullable=False)
```