This needs unit tests and a full integration test.

Pushing this as an initial checkpoint.

The number of objects returned by the infoblox api is limited to 1000 objects
(see https://ipam.illinois.edu/wapidoc). If there are more then 1000 objects
the API returns an error. By setting max-results one can raise the limit.

The --istio-ingress-gateway flag may now be specified multiple times.

number of retries that API calls will attempt before giving up.

This somewhat mitigates the issues discussed in #484 by allowing
the current sync attempt to complete vs. failing and starting anew.

Defaults to 3, which is what the aws-sdk-go defaults to where not
specified.
Signed-off-by: Joe Hohertz <joe@viafoura.com>

This is to change the way batching works when using the aws provider.
Originally, batching would take the first n records you want to update
and perform the desired actions on those records as part of a sync. It
would then wait for the configured sync period and take the first n
records again and sync them. The issue with this is that when you are
using the TXT registry with a custom prefix, the updates can sync a TXT
record and not the accompanying A/CNAME record. This causes external-dns
to get out of sync with what is created and what the current state
actually is. This update uses the same idea of batching, however, rather
than stopping after the first batch until the next run, batching will
now have a separate batch interval which controls the interval between
each batch in the same sync period. This allows external-dns to fully
sync with route53 as part of each sync and can then know that the state
is complete.

Fixes https://github.com/kubernetes-incubator/external...

* add Istio Gateway Source

* add documentation for Istio Gateway Source

* make both istio namespace and ingress gateway service configurable

* prefix gateway types, constructors, and flags with 'istio-'

* fix: add missing sources to source flag docs

When running in a pod sometimes the request to get ingreses/services
stalls indefinitely. A simple pod restart fixes this. Hard to reproduce
but I got lucky and did thread dump which revealed a gorouting blocked
on call to k8s.

What's new is a `--request-timeout` flag that makes requests to k8s
bounded in time. The default is 30s - this may cause some deployments
with a slow api-server to timeout.

* Added HostPort feature docs

* Fixed some typos

* Fixing hostIP,podIP change

Fixing hostIP,podIP change

Merge artifacts in docs

Naming typo

removing unnecessary files

fix(source): fix misleading log message

Naming typo

removing unnecessary files

* fix(source): fix misleading log message

Signed-off-by: Yoan Blanc <yoan.blanc@exoscale.ch>