MFC revs 197129,197130,197132:  Fixes to mcast userland API. --   Fix an API issue in leave processing for IPv4 multicast groups.    * Do not assume that the group lookup performed by imo_match_group()      is valid when ifp is NULL in this case.    * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the      membership we are being asked to leave.
MFC revs 197129,197130,197132:
 Fixes to mcast userland API.
--
  Fix an API issue in leave processing for IPv4 multicast groups.
   * Do not assume that the group lookup performed by imo_match_group()
     is valid when ifp is NULL in this case.
   * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the
     membership we are being asked to leave.

  Caveat user:
   * The way IPv4 multicast memberships are implemented in the inpcb layer
     at the moment, has the side-effect that struct ip_moptions will
     still hold the membership, under the old ifp, until ip_freemoptions()
     is called for the parent inpcb.
   * The underlying issue is: the inpcb layer does not get notification
     of ifp being detached going away in a thread-safe manner.
     This is non-trivial to fix.
--
  Fix an obvious logic error in the IPv4 multicast leave processing,
  where the filter mode vector was not updated correctly after the leave.
--
  Tighten input checking in inp_join_group():
   * Don't try to use the source address, when its family is unspecified.
   * If we get a join without a source, on an existing inclusive
     mode group, this is an error, as it would change the filter mode.

  Fix a problem with the handling of in_mfilter for new memberships:
   * Do not rely on imf being NULL; it is explicitly initialized to a
     non-NULL pointer when constructing a membership.
   * Explicitly initialize *imf to EX mode when the source address
     is unspecified.
  This fixes a problem with in_mfilter slot recycling in the join path.
--
  Don't allow joins w/o source on an existing group.
  This is almost always pilot error.

  We don't need to check for group filter UNDEFINED state at t1,
  because we only ever allocate filters with their groups, so we
  unconditionally reject such calls with EINVAL.
  Trying to change the active filter mode w/o going through IP_MSFILTER
  is also disallowed.

  Deals with the case described in PR 137164 upfront, cumulative
  with the fix in svn rev 197132 which only calls imo_match_source()
  if the source address family was not unspecified.
--

Revision 197136 has a text conflict, however it is a comment only change.

PR:		137164, 138689, 138690, 138691
Submitted by:	Stef Walter (with fixups)
Approved by:	re (kib)

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase