can the mname data in SOA record point to a cname?

Is it possible to have the mname in SOA record point to a CNAME? Example:

;; ANSWER SECTION:
example.com.        1800    IN  SOA ns0.example.com. hostmaster.example.com. 2017071022 3600 300 1814400 600

ns0.example.com.    900 IN  CNAME   realdnsmasterexample.com.
realdnsmaster.example.com. 900 IN   A   10.0.0.1

The reason for this is to add an abstraction layer for our master DNS server so that we have some portability for the master DNS role. We will not be listing "ns0" as a nameserver for the various zones. I cannot find any documentation that says the target for mname has to be of type A or AAAA.

The MNAME field is probably not being used the way that you think it is being used.

Below is a quote from RFC 7719, DNS Terminology. Its status is Informational -- it does not define an Internet Standard -- but it is intended to serve as a reference of terms for DNS administrators relative to practices in 2015. The bolded emphasis is mine.

Primary master: "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR". (Quoted from [RFC1996], Section 2.1). [RFC2136] defines "primary master" as "Master server at the root of the AXFR/IXFR dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone." The idea of a primary master is only used by [RFC2136], and is considered archaic in other parts of the DNS.

RFC 2136 is the only RFC within the DNS standards that defines a software process consuming the value of the MNAME field. It is only used by dynamic DNS client software, and only in cases where the user did not specify the server to execute updates against. It should never be assumed that the MNAME points to anything other than a DNS server that accepts dynamic updates for the zone, as it is the only software that will break when the value is wrong and/or bogus.

...But with the above in mind, if you actually are using the MNAME field to perform automatic detection of your dynamic update endpoint, there's nothing wrong with having it be a CNAME. You won't run up against any of the logical reasons behind why pointing a MX record or NS record at an alias are forbidden by the standards.

It is possible to use a CNAME there. However, if your purpose is to have dynamic nameservers in your NS records as well, you'd still need to update the glue record with whoever you bought the domain from; otherwise they'll keep pointing to the old nameserver, and your domain will become unresolvable.