chore(e2e): downgrade to WebdriverIO v8

[QZera]

Downgrade WebdriverIO and Related Packages from v9 to v8

Reasoning

The wdio-vscode-service package has a peer dependency on WebdriverIO v8. Initially, it seemed that this could be ignored since the tests were running fine. However, there are some incompatibilities in the types between v8 and v9 that have caused issues.

Example

/**
 * Type in v9: any
 * Type in v8: WebdriverIO.Element
 */
const inputElement = await setting.textSetting$

These type incompatibilities have led to confusion and hours of painfully slow debugging. Therefore, I think it best to downgrade to WebdriverIO v8 to ensure compatibility, reduce debugging time and avoid potential issues in the future.

[maninak]

Understood, unfortunate that we can't avoid going with the latest major version.

Could we please squash all those commits, document a summary of the rationale in the single commit and most importantly which specific conditions need to be met before upgrading to v9? Ideally, if there's an appropriate place (eg wdio config file as a comment?) perhaps also copy the conditions for upgrade there for improved visibility. Or write a minimal comment referencing commit body for more info?

Up to you. But I'd like to make sure we preserve in writing for future maintenance the current context you've got and in which we've invested.

EDIT: I see you are using these commits in other open PRs. If it reks your workflow then perhaps it's wiser to skip the commit squashing.

[QZera]

Understood, unfortunate that we can't avoid going with the latest major version.

Could we please squash all those commits, document a summary of the rationale in the single commit and most importantly which specific conditions need to be met before upgrading to v9? Ideally, if there's an appropriate place (eg wdio config file as a comment?) perhaps also copy the conditions for upgrade there for improved visibility. Or write a minimal comment referencing commit body for more info?

Up to you. But I'd like to make sure we preserve in writing for future maintenance the current context you've got and in which we've invested.

Done! Please have a look.

EDIT: I see you are using these commits in other open PRs. If it reks your workflow then perhaps it's wiser to skip the commit squashing.

Ended up squashing, changes are isolated so rebasing the other branches should be trivial.