Improve session docs

[amirhhashemi]

• I have read the Contribution guide
• This PR references an issue (except for typos, broken links, or other minor problems)

Description(required)

This PR improves the Sessions page in the SolidStart docs with a complete rewrite. For more information about the issues that I tried to address in this PR see this Issue.

Related issues & labels

• Closes [Content]: Improvements for the session docs #1034, In the session example code, should 'event.params.userId' be just 'userId'? #835

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[netlify]

✅ Deploy Preview for solid-docs ready!

Name	Link
🔨 Latest commit	9980684
🔍 Latest deploy log	https://app.netlify.com/sites/solid-docs/deploys/67ae1dad53ba7c0008cfee68
😎 Deploy Preview	https://deploy-preview-1072--solid-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for solid-docs ready!

Name	Link
🔨 Latest commit	c8279d5
🔍 Latest deploy log	https://app.netlify.com/sites/solid-docs/deploys/67bf297c206802000951fd45
😎 Deploy Preview	https://deploy-preview-1072--solid-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[LadyBluenotes]

I'm a little iffy about the last point in 4 - it sounds a bit off being on its own.

Suggested change

	A session typically involves:
	1. **Session creation**: When tracking is needed (e.g., upon login or first visit), the server creates a session.
	This involves:
	- Generating a unique **session ID**.
	- Storing the session data _encrypted and signed_ within a cookie.
	2. **Session cookie transmission**: The server sends a `Set-Cookie` HTTP header.
	This instructs the browser to store the session cookie.
	3. **Subsequent requests**: The browser automatically includes the session cookie in the `Cookie` HTTP header for requests to the server.
	4. **Session retrieval and data access**: For each request, the server:
	- Checks for the session cookie.
	- Retrieves session data from the cookie.
	- Decrypts and verifies the signature of the session data.
	- Application code can access and use this data.
	5. **Session expiration and destruction**: Sessions typically expire after a time or upon user logout.
	Destruction involves instructing the browser to delete the session cookie (e.g., setting an expired `Set-Cookie`).
	A session typically involves:
	1. **Session creation**: When tracking is needed (e.g., upon login or first visit), the server creates a session.
	This involves generating a unique **session ID** and storing the session data _encrypted and signed_ within a cookie.
	2. **Session cookie transmission**: The server sends a `Set-Cookie` HTTP header.
	This instructs the browser to store the session cookie.
	3. **Subsequent requests**: The browser automatically includes the session cookie in the `Cookie` HTTP header for requests to the server.
	4. **Session retrieval and data access**: For each request, the server must:
	- Check for any session cookies,
	- Retrieve any session data if a cookie is present,
	- Decrypt and verify the signature of the session data for the application to access and use this data.
	5. **Session expiration and destruction**: Sessions typically expire after period of time or upon user sign-out.
	The browser will delete the session cookie (e.g., setting an expired `Set-Cookie`) in order to destroy it.

[amirhhashemi]

I don't agree with some of the suggestions:

1. In the fourth point, I would remove the "must" and change the bullet points accordingly. We shouldn't "instruct" on this page according to Diataxis and the suggestion has a little instructional tone.

2. In the fifth point, there is a comma at the items, is it a typo?

3. In the fifth point, this part is confusing:

   The browser will delete the session cookie (e.g., setting an expired Set-Cookie) in order to destroy it.

   The browser doesn't set an expired Set-Cookie header to destroy the cookie. That's what the server does to signal the browser to destroy the cookie.

I think I get the heart of the suggestions. I will make some changes accordingly.

[LadyBluenotes]

This might be better suited for a table instead of a list.
In addition, it probably doesn't have to be an ordered list since we aren't talking about a series of events here

[amirhhashemi]

I'm not sure how a table can be used here. I think a bullet list is better. I made some change that hopefully makes this section more clear without using a table.

[LadyBluenotes]

Only use ordered when you're referring to a list of steps that must be performed in order

Suggested change

	1. **Session creation**: When tracking is needed (e.g., upon login or first visit), the server creates a session.
	This involves generating a unique **session ID** and storing the session data, _encrypted and signed_, within a cookie.
	2. **Session cookie transmission**: The server sends a `Set-Cookie` HTTP header.
	This instructs the browser to store the session cookie.
	3. **Subsequent requests**: The browser automatically includes the session cookie in the `Cookie` HTTP header for requests to the server.
	4. **Session retrieval and data access**: For each request, the server:
	1. Checks for the session cookie.
	2. Retrieves the session data if a cookie is present.
	3. Decrypts and verifies the signature of the session data for the application to access and use this data.
	5. **Session expiration and destruction**: Sessions typically expire after a period of time or upon user sign-out and the data is removed.
	This is done by setting a `Max-Age` attribute on the cookie or by sending a `Set-Cookie` HTTP header with an expired date.
	1. **Session creation**: When tracking is needed (e.g., upon login or first visit), the server creates a session.
	This involves generating a unique **session ID** and storing the session data, _encrypted and signed_, within a cookie.
	2. **Session cookie transmission**: The server sends a `Set-Cookie` HTTP header.
	This instructs the browser to store the session cookie.
	3. **Subsequent requests**: The browser automatically includes the session cookie in the `Cookie` HTTP header for requests to the server.
	4. **Session retrieval and data access**: For each request, the server:
	- Checks for the session cookie.
	- Retrieves the session data if a cookie is present.
	- Decrypts and verifies the signature of the session data for the application to access and use this data.
	5. **Session expiration and destruction**: Sessions typically expire after a period of time or upon user sign-out and the data is removed.
	This is done by setting a `Max-Age` attribute on the cookie or by sending a `Set-Cookie` HTTP header with an expired date.

[amirhhashemi]

The server first checks for session cookie, then retrieves the session data ...

It has an order.