Fail build if new doc snippets aren't // CONSOLE

[nik9000]

This tracks the snippets that probably should be converted to
// CONSOLE or // TESTRESPONSE and fails the build if the list
of files with such snippets doesn't match the list in docs/build.gradle.
Setting the file looks like

/* List of files that have snippets that probably should be converted to
 * `// CONSOLE` and `// TESTRESPONSE` but have yet to be converted. Try and
 * only remove entries from this list. When it is empty we'll remove it
 * entirely and have a party! There will be cake and everything.... */
buildRestTests.expectedUnconvertedCandidates = [
  'plugins/discovery-azure-classic.asciidoc',
...
  'reference/search/suggesters/completion-suggest.asciidoc',
]

This list is in build.gradle because we expect it to be fairly
temporary. In a few months we'll have converted all of the docs and won't
ned it any more.

From now on if you add now docs that contain a snippet that shows an
interaction with elasticsearch you have three choices:

1. Stick // CONSOLE on the interactions and // TESTRESPONSE on the
   responses. The build (specifically (gradle docs:check) will test that
   these interactions "work". If there isn't a // TESTRESPONSE snippet
   then "work" just means "Elasticsearch responds with a 200-level response
   code and no WARNING headers. This is way better than nothing.
2. Add // NOTCONSOLE if the snippet isn't actually interacting with
   Elasticsearch. This should only be required for stuff like javascript
   source code or curl against an external service like AWS or GCE. The
   snippet will not get "OPEN IN CONSOLE" or "COPY AS CURL" buttons or be
   tested.
3. Add // TEST[skip:reason] under the snippet. This will just skip the
   snippet in the test phase. This should really be reserved for snippets
   where we can't test them because they require an external service that
   we don't have at testing time.

Please, please, please, please don't add more things to the list. After
all, it sais there'll be cake when we remove it entirely!

Relates to #18160

[nik9000]

I converted these to test the ratcheting behavior locally.

[javanna]

I am not too familiar with the gradle/groovy stuff, but I like the change and I think we should get it in.

[nik9000]

I considered reading these from a file instead but decided it wasn't worth the effort because we should convert all the files before too long, removing the need for the list.

[jimczi]

makes sense though the comment is out of date.

[nik9000]

@jimferenczi and @javanna - pushed a change converting the count to a list which should make this more "git friendly".

[jimczi]

@nik9000 left a very minor comment, LGTM otherwise.

[nik9000]

Thanks for reviewing @javanna and @jimferenczi! I fixed the comment and merged. I'll cherry-pick into the 5.x branch now.

[nik9000]

5.x: 15a4214

[dadoonet]

@nik9000 Could you also backport this change to 5.0 branch?

[nik9000]

@nik9000 Could you also backport this change to 5.0 branch?

Technically I can, but I didn't want to destabilize that branch. The version conflicts every time you backport a change to the unconverted list to 5.0 are a huge pain though.