Do not render irrelevant docs for apm server. (elastic#6841)

Avoid rendering information about `monitoring` and
`template.append_fields` as this cannot be used for APM.

libbeat/docs/security/securing-beats.asciidoc

@@ -17,13 +17,17 @@ In addition to configuring authentication credentials for the {beatname_uc}
 itself, you need to grant authorized users permission to access the indices it
 creates. See <<beats-user-access>>.
 
+ifeval::["{beatname_lc}"!="apm-server"]
 If you plan to monitor {beatname_uc} in Kibana, you must also 
 <<beats-system-user,configure the `beats_system` built-in user>>.
+endif::[]
 
 For more information about {security}, see
 {xpack-ref}/xpack-security.html[Securing {es} and {kib}].
 
 include::basic-auth.asciidoc[]
 include::user-access.asciidoc[]
 include::tls.asciidoc[]
+ifeval::["{beatname_lc}"!="apm-server"]
 include::beats-system.asciidoc[]
+endif::[]

libbeat/docs/template-config.asciidoc

@@ -82,7 +82,8 @@ setup.template.overwrite: false
 setup.template.settings:
   _source.enabled: false
 ----------------------------------------------------------------------
-
+ifeval::["{beatname_lc}"!="apm-server"]
 *`setup.template.append_fields`*:: A list of of fields to be added to the template and Kibana index pattern. experimental[]
 
 NOTE: With append_fields only new fields can be added an no existing one overwritten or changed. This is especially useful if data is collected through the http/json metricset where the data structure is not known in advance. Changing the config of append_fields means the template has to be overwritten and only applies to new indices. If there are 2 Beats with different append_fields configs the last one writing the template will win. Any changes will also have an affect on the Kibana Index pattern.
+endif::[]