Provide an ability to request libnetwork contact the network/IPAM plugin in a future time

The primary driver of this issue is DHCP. The libnetwork remote API (as far as I understood it) has it contacting a network/IPAM remote plugin when a container is created and when it is destroyed. But there are times when an IPAM driver may want to be contacted again between those events.

The only example I have right now is DHCP lease renewal, although I can imagine there would be others.

There are several possibilities:

1. Provide a remote API to libnetwork. When an IPAM driver gives an address, it will be able to contact docker engine / libnetwork in the future and tell it to renew/expire/etc. an address. This seems very messy to me, and breaks the cleanliness of a plugin responding to requests. It also creates lots of security questions, not to mention tracking how it was contacted, etc.
2. Have libnetwork poll a plugin to check if anything has changed or needs to be changed. This seems burdensome. In any case, in most cases, it simply will be unnecessary.
3. Enable libnetwork to be told, "check back with me in X seconds."

The third option seems cleanest. It remains a libnetwork->plugin API, plugins do not need to keep track of where and how to contact a libnetwork to whom it gave an address, and communication occurs only when necessary.

The flow might look like this:

1. Container starts (unchanged)
2. libnetwork contacts plugin requesting IP (unchanged)
3. plugin returns IP information, along with a "check address validity in X seconds" (NEW). Note: if the "check": 3600 field does not exist, then libnetwork works exactly as today: assign the IP and let it go.
4. In X seconds (3600 in the example above), libnetwork contacts IPAM again and asks to revalidate the assigned address.
5. The plugin returns one of the following statuses:
   • valid: libnetwork does nothing, since all is fine. May also include "check again in X seconds" field.
   • invalid: libnetwork removes the address
   • address: a new address, of exactly the same structural format format as if it had contacted libnetwork on creation and should be assigned.

This is my first attempt. Thoughts?

Start by reviewing libnetwork’s existing remote API and IPAM plugin flow for container creation and destruction. Compare that behavior with the proposed delayed revalidation sequence, including valid, invalid, and replacement-address responses. Done would require an agreed API design and implementation scope; this issue names no files or tests.