Rebrand Cisco Spark notify to be Cisco Webex Teams

[fbradyirl]

Description:

• Cisco Spark is now called Cisco Webex Teams. This is to rebrand the component.
• Switch to new pypi: https://pypi.org/project/webexteamssdk
• Move to new component layout.

Since ciscosparkapi pypi will be unsupported towards the end of 2019, it is a good idea to move to the replacement webexteamssdk pypi module.

Pull request in home-assistant.io with documentation: home-assistant/home-assistant.io#8919

Example entry for configuration.yaml:

notify:
  - name: NOTIFIER_NAME
    platform: cisco_webex_teams
    token: YOUR_BOT_TOKEN
    room_id: CISCO_WEBEX_TEAMS_ROOMID

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• New dependencies have been added to the REQUIREMENTS variable (example).
• New dependencies are only imported inside functions that use them (example).
• New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
• New files were added to .coveragerc.

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[fbradyirl]

cc @shenning00

[andrewsayre]

The only breaking change to the config is the platform name. What do we think about retaining the old platform but updating it to print a deprecation warning and then import the new platform's logic? Not sure how feasible that is, but, it would give folks time to adjust their config before things break. @balloob thoughts?

[fbradyirl]

The only breaking change to the config is the platform name. What do we think about retaining the old platform but updating it to print a deprecation warning and then import the new platform's logic? Not sure how feasible that is, but, it would give folks time to adjust their config before things break. @balloob thoughts?

Personally, I would be in favour of a clean break. The user would see in the logs that the platform doesn't exist, and go from there. However, I am not against a type of platform deprecation if such a method exists, or has happened in the past?

[awarecan]

You can leave a mock spark platform, only purpose of it is to print out warning message with how to migrate instruction.

[fbradyirl]

would there be a way to tell the user via Notification Center? Or must we rely on them checking the logs?

[awarecan]

The error message can be trigger by schema validation, that is in very early stage of start up, user can also validate their current config by our command line script, and even before they upgraded by hassio check config add-on

So, a configuration validation error is better IMO.

[fbradyirl]

Are folks happy with this PR or do you require changes?

[MartinHjelmare]

Please rebase on latest dev and solve the merge conflict.

[MartinHjelmare]

Looks good! Add the component package to .coveragerc, and see my comment below.

Can be merged when build passes and those things are fixed.

[MartinHjelmare]

We should remove the breaking change label, right?

[awarecan]

Still breaking change?

[robbiet480]

Nope, @MartinHjelmare already said we could remove the label