Improve invalidation of stored service password if the endpoint URL is changed

A number of issues were found in !1490 (merged) and !1558 (merged) (triggered by support request 7395)

• It is not possible to set a new URL and a password at the same time (new password is ignored)
• An error occurs on the Service Templates admin pages (prop_updated? was referencing the service's project, which is not defined for templates)
• Passwords are reset on every save in Service Templates admin pages

This should fix these 3 issues by respectively:

• Differentiating a property that has been assigned a new value (regardless of the new value) and a property that has been assigned a new value that is different from the old one
• Providing an alternate implementation to detected updated properties, not relying on the service's project
• Filtering an empty password parameter passed to the Service Templates admin page like on the project service page

NB: I did not include a CHANGELOG entry as this is an improvement of features that are already in the list for 8.1, and it felt like an extra entry would be a bit redundant

cc @vsizov

BTW, this MR applies stored service password invalidation to the Jira service in EE: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/32 (together with providing a way to configure the Jira API URL, in order to support a scenario where Jira is not installed at the root of the web server)

Added 36 commits:

• f48e563c...07101cfa - 35 commits from branch gitlab-org:master
• b4639754 - Improve invalidation of stored service password if the endpoint URL is changed

Milestone changed to Support

Reassigned to @vsizov

Status changed to merged

mentioned in commit 2fb02f92

Thanks

I will refactor it tomorrow since it's confusing to me that we have prop_modified? and prop_updated? method. I had to be more careful before merging this. Sorry

mentioned in merge request !1594 (closed)

I reverted this implementation by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1595

and here is my implementation https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1594

mentioned in merge request !1594 (closed)

@vsizov I agree these 2 methods prop_modified? and prop_updated? can cause confusion and I would do without them if possible, but after carefully looking at the problem my conclusion is that it's necessary to have both in some form or another... Maybe different names could make the logic more clear?

Well, I may have an idea to rewrite it a bit in a way that removes possible confusion. I'll submit another MR tomorrow.

mentioned in merge request !1600 (merged)

Yes, I think it's more like naming issue.

maybe method is_touched? would be better? what do you think @cernvcs?

mentioned in commit 62bf2eb8