they still don't pass but they are getting closer

renamed testing/requestWorkspaceDocuments -> testing/workspaceDocuments and put in some more asssertions

This prevents it from spewing an error over a graphql call

DocumentCodeTest is still failing

was failing during tests

## Test plan

Add account that exists 
1. Using settings, add the account that already exists in the list

… having a pro llm selected before (#1866)

## Test plan
1. Having a pro account
2. switch to a pro llm in the chat
3. remove the token from the web 
4. re-authenticate via github

Closes
https://linear.app/sourcegraph/issue/CODY-988/p1-authorization-and-log-in-log-out

## Test plan

Repeat for dotcom and enterprise user account:

**Scenario 1** 

1. Remove all existing accounts
2. Make sure you are redirected to the login panel
3. Login using one of the available providers
4. Make sure that both `cody.auth.login/clicked` and
`cody.auth.signin.token/clicked` telemetry events were fired

**Scenario 2** 

1. Click on Cody status bar and choose `Manage Accounts`
2. Click to add new account
3. Make sure that  `cody.auth.login/clicked` was fired
4. Fill the account details (server and token) and confirm 
5.  Make sure that  `cody.auth.signin.token/clicked` was fired

No functional changes. Features should work as before.

## Test plan
1. Sign in panel features working

## Test plan
Delete the token from the keychain externally 
You can run a separate instance of IDE and remove the account there.

1. Log in to the account
2. Open another IDE, log in to the same account, apply, then remove the
account, apply
3. Switch back to the first ide
4. Close and reopen the project
5. Login panel visible

## Test plan
1. `Sign In with <>` and `Get started` buttons work

…where (#1872)

Closes
https://linear.app/sourcegraph/issue/CODY-2130/improve-how-actions-appear-in-shiftshift-menu

## Changes

I moved action properties like `text` and `description` to `plugin.xml`.
It is just easier to edit and inspect this way.
To be honest, Geminit 1.5 did most of the work:

> Given the following plugin.xml file and properties file, please modify
plugin.xml so each action have additional propertes `text` and
`description` with values from properties file.
> Additionally for every action please add such tag: `<override-text
place="GoToAction" text="Cody: $TEXT"/>` where `$TEXT` is taken from
properties file as well.
> For some actions like: `<action
id="Cody.Accounts.LogInToSourcegraphAction"
class="com.sourcegraph.cody.config.LogInToSourcegraphAction"/>` you may
have to change them to form such as:
> ```
> <action id="Cody.Accounts.LogInToSourcegraphAction"
class="com.sourcegraph.cody.config.LogInToSourcegraphAction" text="Log
In to Sourcegraph">
> <override-text place="GoToAction" text="Cody: Log In to Sourcegraph"/>
> </action>
>```
>
> Please output whole content of the modified plugin.xml file.


## Test plan

1. Hit `Shift shift`
2. Type 'Cody:'


![image](https://github.com/sourcegraph/jetbrains/assets/1519649/5ffd1d07-0088-4cb6-b5c8-3894b281bbe1)

1. Bump cody commit to include changes from
sourcegraph/cody#4766
2. Add startup telemetry event.
I realised that only v2 telemetry events sent directly from IJ contains
info about IDE version and we want to have at least one such event for
every user IDE. Install action telemetry event would not be sufficient
because it would not tell us anything about existing installations.

Same as in sourcegraph/cody#4766

Add the missing value for the ollama docs

## Test plan

<!-- All pull requests REQUIRE a test plan:
https://sourcegraph.com/docs/dev/background-information/testing_principles

Why does it matter?

These test plans are there to demonstrate that are following industry
standards which are important or critical for our customers.
They might be read by customers or an auditor. There are meant be simple
and easy to read. Simply explain what you did to ensure
your changes are correct!

Here are a non exhaustive list of test plan examples to help you:

- Making changes on a given feature or component:
- "Covered by existing tests" or "CI" for the shortest possible plan if
there is zero ambiguity
  - "Added new tests"
- "Manually tested" (if non trivial, share some output, logs, or
screenshot)
- Updating docs:
  - "previewed locally"
  - share a screenshot if you want to be thorough
- Updating deps, that would typically fail immediately in CI if
incorrect
  - "CI"
  - "locally tested"
-->

![Screenshot 2024-07-03 at 12 19
49 PM](https://github.com/sourcegraph/jetbrains/assets/68532117/bb29c397-a40e-453f-b8bf-010e169de863)

Our current setup produces a lot of stable releases that often are not
unhidden eventually. That makes the QA and awaiting JB approval process
parallel. Based on the recent experience only 1/8 releases goes public.
That is a waste of JB approval team's time and CI time.

Let's change the setup. The nightly version handling does not change but
the default release script does not longer publish the stable version.
Instead the separate workflow can be triggered on the specific tag that
publishes the stable version.

## Test plan
1. push a tag for a nightly release
2. trigger the stable release manually

to be tested once merged

Closes
https://linear.app/sourcegraph/issue/CODY-2095/organize-keymap-settings

## Changes

1. Proper grouping was added for all actions in plugin.xml
2. The same grouping is used for nice visual organisation of keymap
management

## Test plan

Visual verification in `Settings > Keymap` (see screenshots):


![image](https://github.com/sourcegraph/jetbrains/assets/1519649/b5292cfb-5a2f-47ae-9706-512fb2675b8a)

![image](https://github.com/sourcegraph/jetbrains/assets/1519649/5553077a-c21e-4003-b1c8-0c2f279f6467)

## Test plan

Full QA according to a test plan.
As for launch script args change that is covered by automatic tests.