Introduce std::string_view into wider use

[sfan5]

lots of general conversion and many low hanging fruits

To do

This PR is Ready for Review.

How to test

1. check that nothing is broken (somehow)

[appgurueu]

Code looks good. Haven't smoke-tested yet.

[Desour]

For the future, it would be nice if we could handle the use of std::string_view like const correctness:

void fun(const T *); // if this is good enough
void fun(T *); // then don't use this

void fun(std::string_view); // if this is good enough
void fun(const std::string &); // then don't use this

[Desour]

It only leads to UaFs if the string view is accessed outside of the full expression, right?
So std::string a = std::string(trim(func_that_returns_str()));, for example, should be fine anyways.

It's a bit weird to have two trim with different signatures. Could rename them to trim_v and trim_s.

[sfan5]

I think that should be fine yes.
The problem would exist if you do auto a = trim(func_that_returns_str());. The string goes out of scope at the end of the line.

Generally I did this so I don't have to touch the many usages of trim that work like this.
I can add a // TODO: this function should be removed or renamed to trim_s to make the distinction clear. if you think that's a good idea.

[Desour]

I can add a // TODO: this function should be removed or renamed to trim_s to make the distinction clear. if you think that's a good idea.

Idk. I guess the overloaded trim is fine for now. ¯\_(ツ)_/¯

[sfan5]

For the future, it would be nice if we could handle the use of std::string_view like const correctness:

Definitely. Feel free to write this down in the guidelines.

[Desour]

Tested shortly with asan, ubsan and leaksan. Found no issues.

Definitely. Feel free to write this down in the guidelines.

Done.

[SmallJoker]

LGTM. Thank you.