The AM should decode both parts of the message. The {@link
 * StrictPreemptionContract} specifies particular allocations that the RM
 * requires back. The AM can checkpoint containers' state, adjust its execution
 * plan to move the computation, or take no action and hope that conditions that
 * caused the RM to ask for the container will change.
 * <p>
 * In contrast, the {@link PreemptionContract} also includes a description of
 * resources with a set of containers. If the AM releases containers matching
 * that profile, then the containers enumerated in {@link
 * PreemptionContract#getContainers()} may not be killed.
 * <p>
 * Each preemption message reflects the RM's current understanding of the
 * cluster state, so a request to return <em>N</em> containers may not
 * reflect containers the AM is releasing, recently exited containers the RM has
 * yet to learn about, or new containers allocated before the message was
 * generated. Conversely, an RM may request a different profile of containers in
 * subsequent requests.
 * <p>
 * The policy enforced by the RM is part of the scheduler. Generally, only
 * containers that have been requested consistently should be killed, but the
 * details are not specified.
The AM should decode both parts of the message. The {@link
 * StrictPreemptionContract} specifies particular allocations that the RM
 * requires back. The AM can checkpoint containers' state, adjust its execution
 * plan to move the computation, or take no action and hope that conditions that
 * caused the RM to ask for the container will change.
 * <p>
 * In contrast, the {@link PreemptionContract} also includes a description of
 * resources with a set of containers. If the AM releases containers matching
 * that profile, then the containers enumerated in {@link
 * PreemptionContract#getContainers()} may not be killed.
 * <p>
 * Each preemption message reflects the RM's current understanding of the
 * cluster state, so a request to return <em>N</em> containers may not
 * reflect containers the AM is releasing, recently exited containers the RM has
 * yet to learn about, or new containers allocated before the message was
 * generated. Conversely, an RM may request a different profile of containers in
 * subsequent requests.
 * <p>
 * The policy enforced by the RM is part of the scheduler. Generally, only
 * containers that have been requested consistently should be killed, but the
 * details are not specified. | PreemptionMessage.java