[Nestmates] RFR: 8197395: [Nestmates] VerifyAccess.isMemberAccessible must not allow private access between legacy nested types

[David Holmes]

bug: https://bugs.openjdk.java.net/browse/JDK-8197395
webrev: http://cr.openjdk.java.net/~dholmes/8197395/webrev/

Here's the original code checking private access in 
VerifyAccess.isMemberAccessible:

  case PRIVATE:
      // Loosened rules for privates follows access rules for inner classes.
      return (ALLOW_NESTMATE_ACCESS &&
             (allowedModes & PRIVATE) != 0 &&
              isSamePackageMember(defc, lookupClass));

ALLOW_NESTMATE_ACCESS was always false as it's an experimental field. So 
for private access the above will always return false - both for 
nestmate classfile versions and earlier. In short no nestmate access 
allowed when defc and lookupClass are distinct. (Lookup.in handles the 
defc==lookupClass case and that is checked earlier.)

For nestmates I modified the above to be:

  case PRIVATE:
      // Loosened rules for privates follows access rules for inner classes.
      return ((allowedModes & PRIVATE) != 0 &&
              isSamePackageMember(defc, lookupClass));

where isSamePackageMember() only did Reflection.areNestMates(). So this 
could return true for nestmate classfiles, but always false for older 
classfiles. Which was exactly what we wanted.

With the fix for JDK-8196320 however, isSamePackageMember() (now renamed 
to areNestMates) first checks Reflection.areNestMates() and then if that 
is false, the old enclosing-class check. Consequently the check can now 
return true for both nestmate classfiles and earlier classfiles! That is 
wrong.

To fix this we replace the call to VerifyAccess.areNestMates() with 
Reflection.areNestMates().

There is also a temporary psuedo-assertion verifying that if we've 
granted private nestmate access then refc==defc (which should be assured 
by the resolution of the member being accessed).

Testing:
  - runtime/Nestmates
  - java/lang/invoke

Thanks,
David