feat: add session and connection properties to QueryJobConfig

[tswast]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes internal issue 202792922 🦕
Closes #1026
Closes #1029

[plamut]

Don't know the exact acceptance criteria for this addition, but at a face value it more or less looks good to me. Had just a few nit comments about type annotations and docstrings.

[plamut]

Looks good, just a question about exposing SessionInfo in the generated docs.

[plamut]

(nit) Explicitly inheriting from object is not needed.

Also, shouldn't we expose this class in the top level namespace? And both new classes in the reference docs?

[tswast]

Added to docs via job_base.rst and query.rst. I noticed in #1023 that we'd missed a few classes, so I migrated some docs back to automodule. Even though I don't think it's the best UX to have so many classes in one page, I'd rather we not forget in the future.

[plamut]

#1029 is not that much different, the differences are the following:

• No SessionInfo class, session_id is exposed directly on the QueryJob instance (similarly to query stats, e.g. estimated_bytes_processed).
• Accepting None as a valid value, the new properties has mostly been marked as Optional[...]
• Contains a fix for the script_options's docstring.

[tswast]

No SessionInfo class, session_id is exposed directly on the QueryJob instance (similarly to query stats, e.g. estimated_bytes_processed).

That makes sense, but I'd rather stick with a close mapping to the actual REST API. I suspect it's a class because they might want to add a lot more session-related stats in the future.

Accepting None as a valid value, the new properties has mostly been marked as Optional[...]

The docs at https://cloud.google.com/bigquery/docs/reference/rest/v2/ConnectionProperty don't appear to indicate that key/value are optional. I'm not sure how useful a connection property will be without a key/value. Certainly the two existing ones require something for both.

Contains a fix for the script_options's docstring.

Good catch. Done!