Convert AJAX part of \Drupal\config\Tests\ConfigEntityTest::testCRUDUI to JavascriptTestBase

I converted the test and created a full convert and a partial convert.

Both patches retain the original test as it tests the non-js functionality as well.

The partial test only covers the AJAX part of the test in the functional javascript test.
The full test covers everything except the non-js validation in the functional javascript test.

I'm not sure which test is preferred. The full test does test 1 additional JavaScripty thing: opening the other actions pulldown and assert the delete button is visible.

Not sure on which test should go in, I'll leave that up to the reviewer :)

Would like some feedback on which test should go in before fixing the full test.

@vaplas nice work! I tried to reproduce the fails in #8, but couldn't. Why was ->find('css', 'xxxxx') causing problems?

Looking at this, this looks like a great conversion of the original coverage. I think you got everything.

Some nits:

1. +++ b/core/modules/config/tests/src/FunctionalJavascript/ConfigEntityTest.php
   @@ -0,0 +1,160 @@
   + * Tests the View UI filter criteria group dialog.
   

   Copy/paste left over

2. +++ b/core/modules/config/tests/src/FunctionalJavascript/ConfigEntityTest.php
   @@ -0,0 +1,160 @@
   +    $assert_session->statusCodeEquals(200);
   ...
   +    $assert_session->statusCodeEquals(200);
   ...
   +    $assert_session->statusCodeEquals(200);
   ...
   +    $assert_session->statusCodeEquals(200);
   ...
   +    $assert_session->statusCodeEquals(200);
   ...
   +    $assert_session->statusCodeEquals(200);
   

   Don't use this please, it will be removed soon, I think we can just leave it out of this test, since after all the calls there are proper assertions to the content of the page. So the statusCodeEquals calls serve not real purpose here anyway

3. +++ b/core/modules/config/tests/src/FunctionalJavascript/ConfigEntityTest.php
   @@ -0,0 +1,160 @@
   +    $assert_session->assertWaitOnAjaxRequest();
   

   Please try to stay away from assertWaitOnAjaxRequest(), use waitForElement and the methods like that. So be specific about what you are waiting for, this cuts down on possible random fails

I like the idea of waiting vs finding but:

Patch in #13
Time: 38.64 seconds, Memory: 6.00MB

OK (1 test, 13 assertions)

Process finished with exit code 0

Patch in #17
Time: 1.16 minutes, Memory: 6.00MB

OK (1 test, 21 assertions)

Process finished with exit code 0

It doubles the run time of the test, so lets just use find. Or are there some faulty waits in there that actually run the full length of the wait?

+++ b/core/modules/config/src/Tests/ConfigEntityTest.php
@@ -317,29 +317,17 @@ public function testCRUDUI() {
+    // Test the same scenario but it in a non-JS case by using a 'js-hidden'
+    // submit button.

It's not really the same scenario anymore, since the js version is removed.

"Create a configuration entity with a property that uses AJAX to show extra form elements. Test this scenario it in a non-JS case by using a 'js-hidden' submit button.
@see \Drupal\Tests\config\FunctionalJavascript\ConfigEntityTest::testAjaxOnAddPage"

Something like that?

Committed/pushed to 8.5.x and cherry-picked to 8.4.x. Thanks!