refactor: prepare 0.8 for applying changes from 'curamenta' (EC-7)

[pi-314]

• Fixes multiple issues with config.sample.yaml and logging.
• Bumps multiple deps and dev-deps.
• Improves documentation in README.md
• Improves npm scripts for local debugging.

[CLAassistant]

All committers have signed the CLA.

[emgrav]

I would also like to see the commit messaged changes a bit more, to ensure they match our style and convention. For example, when we use scopes, it's to denote which component was changed when committing in a monorepo, for example refactor(matrix) in a WFE commit to denote wfs-matrix. My suggestions for these commit messages:

4e5483fa10cbb05542012ad6d830442321f65610 docs: update GitLab->GitHub repo URL in README.
docs: Update repo URL in README

f406ffef82baa19a25e9d1168f7fb5a87d6b1381 refactor(deps): switch famedly-matrix-middleware from GitLab to GitHub
chore: Update famedly-matrix-middleware dependency

3a9de41f3b26cc26cd49ec9ecffdc7cf12b4b605 chore(deps): bump multiple deps and dev-deps to fix npm audit findings.
bump: Update dependencies

3174224d173ee9b88ea96a37dc3704413e6bfbaf test: fix test_config does't fail on incomplete configuration.
test: Ensure test_config fails when configuration is incomplete

bc637bf079a3db7ac810628fe59ea3945ee03541 fix: crash on startup due to missing stageAliases{} in config.sample.yaml
chore: Add missing directives to sample configuration

a1615bbb5a563b28dd5d9a800130700153039177 fix: log files created at wrong location, crash on startup if not root.
refactor: Split log config into two directives, adjust sample config
(Is this a change that requires infra to change anything in the collection? If so, should it be breaking? (refactor!: [..] )

86f56130741d4c24439a5b7d17319abde94338ad refactor: Introduce helper npm scripts to simplify local testing
feat: Add helper npm scripts

c81c7506bb92460d6c8a8473e7acfca8981facc8 docs: Add chapter 'Working with project'
doc: Add chapter 'Working with project' 

85b8fbdd1e407e08a723ec3c68cf3366bbeb63b5 docs: Add chapter 'Logs and log rotation' to 'Configuration' and restructure document.
doc: Add chapter 'Logs and log rotation', restructure document

b64ccf7003e5f2bb58d7cac7bf223cafdc836dc5 docs: Add chapter 'Web server binding'
doc: Add chapter 'Web server binding'

f3c87eaf9379aec8b71d8ce7d5aebafa6779f7f3 refactor: disabled Gitlab specific workaround for certificates.
chore(docker): Disable Gitlab-specific TLS workaround

476f510617339474a4bb9eba34fa9df4c0c271fc (HEAD -> piov/v0.8.5-FixAndRefactoring, origin/piov/v0.8.5-FixAndRefactoring) refactor: Fix TSLint findings.
refactor: Fix TSLint findings

[pi-314]

Two things regarding commit messages.

1. There are already docs: comments in the repo. Is there a difference between 'docs:' and 'doc:'? For me both are fine, we should just be aware of it.

2. In this repo the convention about 'chore:' and 'bump:' seems to be a bit different. bump: indicates update of an uia-proxy version, while chore: denotes mostly CI refactorings but sometime also dependency updates ('chore: Bump dependencies.') Btw. Dependabot comments also chore(deps): Bumps.... Which of this two convention should we then follow in this repo?

In general: should I rephrase and 'push -force' or maybe there is some other convention on how to rephrase multiple commits?

[emgrav]

Regarding 1: Yeah, we haven't been entirely consistent about these things in the past, hence the push for following convention now. The reason doc matters is partly to leave one more character for the description as the character limit is low, and partly that our git-cliff configuration that we use to generate changelogs only matches on doc. I will send you a link internally.

About two, that's a good point about dependabot, I hadn't noticed. I wonder if we can reconfigure that somehow. I would argue that chore is for miscellaneous fixes not necessarily related to code, whereas bump is to bump dependencies. Hence the categorisation I added to the git docs, it's an attempt to define a convention so that we have one to stick to in the future, to avoid the past situation.

We don't deploy feature branches and generally only one person works on them unless agreed otherwise, so feel free to force push to feature branches, especially ones namespaced piov/. Though as always, it's a good idea to rather use push --force-with-lease to prevent accidents :)