Yes, any existing PostgreSQL server which is part of the same replication cluster can be registered with repmgr. There's no requirement for a standby to have been cloned using repmgr.
This is a two-stage process. First, the failed primary's data directory must be re-synced with the current primary; secondly the failed primary needs to be re-registered as a standby.
In PostgreSQL 9.5 and later, it's possible to use pg_rewind to re-synchronise the existing data directory, which will usually be much faster than re-cloning the server. However pg_rewind can only be used if PostgreSQL either has wal_log_hints enabled, or data checksums were enabled when the cluster was initialized.
repmgr provides the command repmgr node rejoin which can optionally execute pg_rewind; see the repmgr node rejoin documentation for details.
If pg_rewind cannot be used, then the data directory will have to be re-cloned from scratch.
Execute repmgr standby clone with the --dry-run option; this will report any configuration problems which need to be rectified.
Use the command line option --copy-external-config-files. For more details see Copying configuration files.
No, the repmgr shared library is only needed when running repmgrd. If you later decide to run repmgrd, you just need to add shared_preload_libraries = 'repmgr' and restart PostgreSQL.
repmgr and repmgrd need to be able to connect to the repmgr database with a normal connection to query metadata. The replication connection permission is for PostgreSQL's streaming replication (and doesn't necessarily need to be the repmgr user).
Cloning a standby is a one-time action; the role of the server being cloned from could change, so fixing it in the configuration file would create confusion. If repmgr needs to establish a connection to the primary server, it can retrieve this from the repmgr.nodes table on the local node, and if necessary scan the replication cluster until it locates the active primary.
Provide the option --waldir (--xlogdir in PostgreSQL 9.6 and earlier) with the absolute path to the WAL directory in pg_basebackup_options. For more details see pg_basebackup options when cloning a standby.
Under some circumstances event notifications can be generated for servers which have not yet been registered; it's also useful to retain a record of events which includes servers removed from the replication cluster which no longer have an entry in the repmrg.nodes table.