The instance config schema was changed in commit 4bb1eb0e ("config:
remove hashes from credentials.password"), but an example of a config
for etcd was not updated.

The example is tested on Tarantool EE, so we should update it to fix the
testing failure.

Part of #8967

NO_DOC=It is a fix of the testing problem.
NO_CHANGELOG=see NO_DOC
NO_TEST=It is a fix of a test in fact.

Follow-up #9007

NO_DOC=Will be described when full support for vshard is introduced.
NO_CHANGELOG=Addition of an example.

In the initial credentials schema, the hashes were supposed to give a
way to have passwords out of plain-text config file.
Later, it was decided to remove this feature, because this way of
authorisation is inferior to the one with auth service and tokens,
but the latter is out of scope for current config development.
This patch removes `credentials.password.{sha1,sha256}` and moves
plain password from `credentials.password.plain` to `credentials.password`.

Part of #8967

NO_DOC=tarantool/doc#3544 links the most actual schema,
       no need to update the issue.
NO_CHANGELOG=removed feature was not released yet

The following syntax variants are fobidden now:

* user@
* user:pass@
* user@host:port
* user:pass@host:port

Only host:port is allowed (inet URI or unix socket URI).

The idea is that we shouldn't distribute login/password information
using the configuration, so it is better to explicitly forbid such
usage of the option.

Closes #8810

NO_DOC=the old behavior was not released, the documentation request will
       be registered manually
NO_CHANGELOG=see NO_DOC

This failover mode enables automatic leader election on a replicaset.
Assigning a leader manually (`leader` option) and assigning RO/RW mode
(`database.mode` option) are forbidden in this failover mode.

Configuration example:

```yaml
replication:
  failover: election         # !!

groups:
  group-001:
    replicasets:
      replicaset-001:
        instances:
          instance-001: {}
          instance-002: {}
          instance-003: {}
```

All the replicaset instances are so called candidates by default: they
can vote for a leader, they can be elected as a leader. However, it is
possible to set `replicaset.election_mode` to 'voter', 'off' or
'manual'. See more detailed description in the box_cfg applier comments
in the code and in the box.cfg() options documentation [1].

Note: Unlike box.cfg()'s option 'election_mode', the
replication.election_mode = "off" forces the instance to be read-only
(if failover = "election" is enabled). box.cfg() call has no cluster
configuration and it doesn't know, whether the given replicaset is
managed by the built-in election algorithm or an external coordinator.

The election failover may be used to improve cluster's availability.

[1]: https://www.tarantool.io/en/doc/latest/reference/configuration/#cfg-replication-election-mode

Part of #8810

NO_DOC=the old behavior was not released, the documentation request will
       be registered manually
NO_CHANGELOG=see NO_DOC

This failover mode allows to set a leader for a replicaset by its
instance name instead of per-instance database.mode option. For example:

```yaml
replication:
  failover: manual           # !!

groups:
  group-001:
    replicasets:
      replicaset-001:
        leader: instance-001 # !!
        instances:
          instance-001: {}
          instance-002: {}
          instance-003: {}
```

The "manual" failover mode doesn't allow several leaders in a
replicaset. If it is desired, use the "off" failover mode.

The "manual" mode doesn't perform a proper leader switching at the
moment. An administrator should resign the old leader (by unsetting the
leader option or setting it to `null`), wait till all the data arrives
to the upcoming leader and then configure it as the new leader.

The proper leader switching is subject of a future work. Also, the next
commit will add replicaset.failover = "election", which handles such
problems.

Part of #8810

NO_DOC=the old behavior was not released, the documentation request will
       be registered manually
NO_CHANGELOG=see NO_DOC

Enabling read-write by default is unsafe for an instance in a replicaset
with more than one instance. The only meaningful default here is
read-only.

On the other hand, a signleton instance (the only one in its replicaset)
almost always started in the read-write mode in practice.

Let's use these values as defaults for these situations.

The name of the option is changed from `rw` (boolean) to `mode` (enum
with allowed values `'ro'` and `'rw'`). We agreed on the enum after a
long controversy whether it should be `ro` or `rw`.

Part of #8810

NO_DOC=the old behavior was not released, the documentation request will
       be registered manually
NO_CHANGELOG=see NO_DOC

In brief:

* client -- for external clients
* peer -- for connections within the cluster, in particular for replicas
* sharding -- for routers and a rebalancer

See the instance_config.lua file for the details.

Part of #8810

NO_DOC=the old behavior was not released, the documentation request will
       be registered manually
NO_CHANGELOG=see NO_DOC

The following new syntax variants are introduced for `iproto.advertise`.

* `user@` -- use the given user, a password from the `credentials`
  section and `host:port` from `iproto.listen`
* `user:pass@` -- use the given user and password, use `host:port` from
  `iproto.listen`
* `user@host:port` -- use the given user, host and port, use a password
  from the `credentials` section

It allows to don't repeat the same information in different places of
the config.

The `test_no_advertise_*` test cases are generalized: now the same
boilerplate code is used for these and new cases.

The `test.luatest_helpers.server` util gains ability to parse all the
new `iproto.advertise` variants.

The replicaset and etcd configuration examples are updated to use the
`user@` syntax.

Part of #8810

NO_DOC=the old behavior was not released, the documentation request will
       be registered manually
NO_CHANGELOG=see NO_DOC

This patch adds configuration examples. Although the configuration
module will be introduced later, the examples can already be tested
using the instance_config and cluster_config modules.

Closes #8778

NO_DOC=will be added later
NO_CHANGELOG=will be added later

There are two new options introduced in Tarantool CLI:
* --name (-n) to specify instance name to be started. The option can be
  omitted in case TT_INSTANCE_NAME environment variable is set.
* --config (-c) to specify the path to the config file. If the option
  is not set the value of TT_CONFIG environment variable is considered.

Closes #8613

Co-authored-by: Sergey Bronnikov <sergeyb@tarantool.org>

@TarantoolBot document
Title: introduce new CLI options for conf module

There are two new options introduced in Tarantool CLI:
* --name (-n) to specify instance name to be started. The option can be
  omitted in case TT_INSTANCE_NAME environment variable is set.
* --config (-c) to specify the path to the config file. If the option
  is not set the value of TT_CONFIG environment variable is considered.

Synced with description in the README updated in #5679.

Show manual page: pod2man doc/man/tarantool.pod | mandoc -a

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal

Follows up #7456
Follows up #5541

NO_CHANGELOG=doc
NO_DOC=doc
NO_TEST=doc

This commit adds the RFC for the sysprof that
was approved a year ago.

Part of #781

NO_DOC=RFC
NO_TEST=RFC
NO_CHANGELOG=RFC

Fixup of f06417 ("doc: publish autogenerated module api documentation").

https://tarantool.github.io/tarantool/api/html/module_8h.html

NO_CHANGELOG=ci
NO_DOC=ci
NO_TEST=ci

NO_DOC=internal
NO_TEST=internal

Copyright year in manual page is outdated: update copyright year to
2021.

Closes #5309

I think that our current process is better. But if someone will want to
understand why we stick with it, it is good to have explicit cons and
pros.

There is discussion in #5910 about all inconsistencies
we see between Lua and SQL worlds and possible future
directions of SQL development and new types additions.

This RFC is current state of this discussion.

Part of #5910

Co-authored-by: Igor Munkin <imun@tarantool.org>
Co-authored-by: Peter Gulutzan <pgulutzan@ocelot.ca>
Co-authored-by: Mergen Imeev <imeevma@tarantool.org>
Co-authored-by: Sergey Ostanevich <sergos@tarantool.org>

Resolves #5857

Reviewed-by: Igor Munkin <imun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

See https://github.com/tarantool/tarantool/discussions/5634

Part of #5442

Reviewed-by: Sergey Ostanevich <sergos@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

Part of #5187

Part of #1148

As per request by Kostja, commit an RFC document with a brief history of
the vinyl metadata log infrastructure, issues it was intended to solve,
problems we are facing now, and possible ways to solve them.

Part of #4182

Part of #3271

Add description of possible redesigning of vector clocks.

This is a draft paper covering following topics:
1. Draft protocol for discovering and maintaining network topology
in case of large arbitrary network.
2. List of required changes to support this feature.
3. Open questions and alternatives.

Changes in V2:
Based or Vlad's review
1. Rewrite couple sections to make it more clear.
2. Clarify with more details and add examples.
3. Fixed error.

RFC for #3294

Part of #3328

Introducing a formal, trackable process for server enhancement.

Before working on a complex feature, please write an RFC document,
describing what and how you see changed, and get it approved.

All historical RFCs are kept in doc/rfc.

* update tarantool man page
* cross-reference tarantool and tarantoolctl pages

Moved to tarantool/doc repository.

* doc: moved to http://github.com/tarantool/doc