Fix deprecation logic which could auto-enable services

What does this MR do?

Due to the way Gitlab::ConfigMash works, when auto-vivifaction is enabled, [] method will create an empty Hash if the specified key is not present. This means in scenarios where unicorn['enable'] is not at all set in gitlab.rb, when we try to fetch unicorn['enable'] to check for deprecations, because the key enable is not present, it will cause unicorn['enable'] to be an empty Hash. Because we check for nil-ness of service['enable'] to include enable/disable recipes and because an empty hash is not nil, we will end up enabling the unicorn service, and boom!

We should return early if the setting is not at all present.

Related issues

Closes #6126 (closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

• Merge Request Title, and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks
• trigger-package has a green pipeline running against latest commit

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for the GitLab Chart opened