Validate absence of project_id if service template

What does this MR do?

Services are not allowed to be a template and a project service at the same time. Service Templates can be defined on the instance level and get copied and attached to new projects at the time they are created.

Part of #208925 (closed) (6. Validates project_id is nil if template)

Migration output

== 20200305151736 DeleteTemplateProjectServices: migrating ====================
-- execute("DELETE\nFROM services\nWHERE TEMPLATE = TRUE AND project_id IS NOT NULL\n")
   -> 0.0028s
== 20200305151736 DeleteTemplateProjectServices: migrated (0.0028s) ===========

I ran a select query in #database-lab. It returned 0 rows and execution time would be 17.806 ms:

explain SELECT id FROM services WHERE project_id IS NOT NULL AND template=true;

Plan with execution:

 Index Scan using index_services_on_template on public.services  (cost=0.56..13.50 rows=53 width=4) (actual time=17.773..17.774 rows=0 loops=1)
   Index Cond: (services.template = true)
   Filter: ((services.project_id IS NOT NULL) AND services.template)
   Rows Removed by Filter: 35
   Buffers: shared hit=17 read=17
   I/O Timings: read=17.587 

Recommendations:

❗ Specialized index needed – The index(es) currently used does not serve quite well for the needs of this query (notice Rows Removed by Filter: ..., meaning that the index fetched many non-target rows). Consider adding more specialized index(es). Show details

Summary:

Time: 17.911 ms
  - planning: 0.105 ms
  - execution: 17.806 ms
    - I/O read: 17.587 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 17 (~136.00 KiB) from the buffer pool
  - reads: 17 (~136.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

Testing

It should not be possible to build an invalid service from the UI or API. Therefore this MR is difficult to test in staging. We can test basic service behaviour though like creating a service and applying a service template.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team