Add a mechanism to mark TypedData (entities and fields) internal via settings.php

(Uploading @effulgentsia's patch and copying my review into here)

#40 looks like a very elegant solution to this! Bravo.

A few nits, then let's see a full testbot run on it. I can't imagine it'll fail, but it'd be nice to know for sure.

1. +++ b/core/lib/Drupal/Core/Entity/EntityType.php
   @@ -370,6 +372,11 @@ public function set($property, $value) {
   +    if ($this->internalizeViaSettings($this->getClass())) {
   

   Wonder if the method wants to be called "isInternalViaSettings()" to be a bit more clear that we're basically testing a bool. "internalize" as a verb sounds like it might take some action or have a side effect or something, while "is" is very clear. ;)

2. +++ b/core/lib/Drupal/Core/TypedData/InternalizeViaSettingsTrait.php
   @@ -0,0 +1,33 @@
   +/**
   + *
   + */
   

   todo

3. +++ b/core/lib/Drupal/Core/TypedData/InternalizeViaSettingsTrait.php
   @@ -0,0 +1,33 @@
   +  private function internalizeViaSettings($class) {
   

   This also needs a docblock.

4. +++ b/core/lib/Drupal/Core/TypedData/InternalizeViaSettingsTrait.php
   @@ -0,0 +1,33 @@
   +      foreach ($setting['internalize'] as $test_class) {
   +        if (is_a($class, $test_class, TRUE)) {
   

   "test_class" might be misunderstood on a quick glance, or via grep, since we have a metric crapton of "test classes" in core. ;) Perhaps "settings_class"? Or maybe "internal_class" here?

5. +++ b/core/lib/Drupal/Core/TypedData/InternalizeViaSettingsTrait.php
   @@ -0,0 +1,33 @@
   +      foreach ($setting['except'] as $test_class) {
   

   ... and "except_class" here? Or stick with "settings_class" in both?

6. Needs tests (if possible). I don't know if/how we could mock the Settings class since it's so low-level. :/ A functional test of some kind to verify that the thing we said is internal is no longer accessible might also be nice for peace-of-mind that this actually locks down something (although I'm sure we've got other access tests for things where isInternal() returns true. But it'd be nice to make sure we don't accidentally forget to call the "internalize" method in the right spots, or refactor/remove it without noticing, etc.

Otherwise, I love it. ;) Meanwhile, I think this could be a follow-up security hardening "task" that could be done after alpha1 (and perhaps back-ported to 8.6.x), so I don't think we should block jsonapi itself on this. Perhaps we should submit that separately now so as not to bog down this discussion with nitpicky reviews like I've just done. ;)

Otherwise, some kind of agreement/commitment on #3037039: Create a public API for indicating resource types should not be exposed would be nice before we commit #2843147: Add JSON:API to core as a stable module but I don't think we need to *fix* #3037039 first, just agree on the plan.

Thanks!
-Derek

This isn't blocking anything, now that #3037942: Add facility to allow security advisories to advise to disable certain routes to mitigate security risk temporarily seems like the way forward.
In fact, I think this probably is now "won't fix" based on how overloaded and confusing "internal" is in core.
See discussion upstream.

My perspective from #4 still stands:

In fact, I think this probably is now "won't fix" based on how overloaded and confusing "internal" is in core.
See discussion upstream.

*shrug*