Add api-int DNS entry to dnsmasq

[cybertron]

This addresses the need for an api-int name pointing at the api VIP.
However, it will only take effect when dev-scripts is managing the
baremetal bridge. With this method, real deployers would need to
add a CNAME to their DNS in addition to the regular api name.

[celebdor]

Shouldn't it be the other way around? Real environments should reserve a VIP for api-int but its resolution should be entirely on our coredns (possibly coredns auto plugin). They should externally have API pointing to whatever they want, like a hw load balancer or whatever.

Thoughts @russellb @cybertron @bcrochet @yboaronn

[cybertron]

Yes, I agree. I was mostly proposing this because you had mentioned trying to use the same method we used for the api name. I actually prefer #450 because it is more self-contained, but it doesn't work for the bootstrap node because we aren't currently running mdns-publisher there.

[derekhiggins]

Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/617/

[markmc]

Please add a reference in the commit to the background context on the openshift change - e.g. openshift/installer#1633 is a good reference

[russellb]

I'd also like to see a reference to an issue somewhere where we are tracking a solution that drops this as an external requirement. Our design goal has always been to completely automate all DNS requirements that are internal to the cluster. This fits that criteria. I don't think we can ship a requirement to have api-int in external DNS.

[cybertron]

I don't think we actually want this change. In @stbenjam 's testing it didn't create api-int where it needed to be. In #523 api-int is being added to dnsmasq in a different place that does work.