Update docs for errors

[andreyaksenov]

Updated docs for the box.error module and some related topics:

• The root Submodule box.error topic now has the overview on how to use the API: https://docs.d.tarantool.io/en/doc/box-error/reference/reference_lua/box_error/
• The error_object description now contains attributes related to replication errors (for example, error_object.reason and related attributes): https://docs.d.tarantool.io/en/doc/box-error/reference/reference_lua/box_error/error_object/
• Made some cosmetic updates in the Database error codes topic: https://docs.d.tarantool.io/en/doc/box-error/reference/reference_lua/errcodes/

The error_marshaling_enabled option was removed in 2.10:

• https://docs.d.tarantool.io/en/doc/box-error/reference/reference_sql/sql_statements_and_clauses/#set
• https://docs.d.tarantool.io/en/doc/box-error/reference/reference_lua/box_space/_session_settings/

The updated docs use testable code snippets from the code_snippets folder. The referenced code snippets is included to help pages using special -- snippet_start and -- snippet_end comments.

[sergepetrenko]

Thanks for working on this!

Just one comment from me.

[p7nov]

Great 👍
Some comments from my side.

[p7nov]

This snippet works as a whole, but when I run only box.error(custom_error, I get box.error(): bad arguments for some reason:

tarantool> local custom_error = box.error.new({ code = 500,
                                     reason = 'Internal server error' })

box.error(custom_error)
---
- error: Internal server error
...

tarantool> box.error(custom_error)
---
- error: 'box.error(): bad arguments'
...

[andreyaksenov]

Looks like this issue is related to a variable visibility scope - local variables are not available in the next console console operation. If you declare custom_error without the local modifier, all should work fine.

[p7nov]

Suggested change

	* :ref:`box.error({ reason = string[, code = number, type = string] }) <box_error-error-table>` accepts a Lua table that enables you to specify the error reason, code, and type.
	* :ref:`box.error({ reason = string[, code = number, type = string] }) <box_error-error-table>` accepts a Lua table containing the error reason, code, and type.

"table enables you to specify" sounds wordy and vague.

[p7nov]

Suggested change

	``ClientError`` or ``OurOfMemory``.
	``ClientError`` or ``OutOfMemory``.

[p7nov]

Suggested change

	This example shows how to raise an error with the specified type and reason:
	This example shows how to raise an error with the type and reason specified
	in the ``box.error()`` arguments:

To highlight the difference with error parameters in a table.

[p7nov]

Maybe add a link to descriptions of specific parameters in error_object reference?

[p7nov]

Suggested change

	Create the error defined by the specified parameters.
	Create an error object with the specified parameters.

To avoid unnecessary passive voice.
Also, the point that this method does not raise the error looks useful to me here.

[p7nov]

Maybe use a unified note or intro phrase for all parameters that apply only to readonly error?
"Only for box.error.READONLY:"

[andreyaksenov]

The following intro already used for such parameters: For the ``box.error.READONLY`` error,. Here I use a slightly different description because this is the 'base' property for a read-only error and box.error.READONLY already mentioned in the description.