Use RwLock for active collectors collection

[TheCataliasTNT2k]

One of the main functions used a Mutex to guard a shared variable.
This may not impact small bots, but can significantly slow down bots, which have a huge volume of GatewayEvents.
This Pullrequest replaces these Mutexes with a RwLock, which allows multiple simultaneous readers.
This should not break any existing code.

[GnomedDev]

This is a breaking change, please re-target to the next branch.

[TheCataliasTNT2k]

I do not know, what this should break, I tested it with current and it worked without any other additions, but I changed it.

[GnomedDev]

let mutex = Arc::new(tokio::sync::Mutex::new("".to_string()));
Shard::new(mutex, "", shard_info, GatewayIntents::all(), None).await?;

This is an example of user code that would break if this PR was merged. Breaking changes means any public API change that stops compilation, with few exceptions. This PR now needs rebasing to drop the extra commits from current and to solve the conflicts.

[TheCataliasTNT2k]

Ah, I forgot about the ws_url, I see. I will hust rebase it onto next, this should be enough.

[TheCataliasTNT2k]

I now got a lot of "Unresolved reference: instrument", but I ignored them, because they already existed on the branch.

[GnomedDev]

Disable the tracing_instrument feature in your builds, it is currently broken, that will get those errors to go away.

[TheCataliasTNT2k]

I did not get build errors, cargo test --features full runs successfully, jut my IDE is very unhappy.

[GnomedDev]

Yes, but you have probably enabled --all-features in your IDE, so it enables the broken feature.

[TheCataliasTNT2k]

I will let rustfmt fix the linter issue.
What to do about the other linter issue? Should I really create a new type alias for that?

[TheCataliasTNT2k]

Too stupid to see errors sometimes...

[GnomedDev]

Looks good to me, thanks for the PR!

[TheCataliasTNT2k]

Thanks for the help!