Feat: Add repeater hop limit specifically for advertisement packets

[Steve-7acc]

This PR introduces a user-defined hop limit specifically for advertisement packets, similar to the existing flood.max implementation, using a new command set/get advert.max.hops.

Currently, our network is seeing a high volume of advertisement traffic travelling excessive distances (40+ hops), which consumes significant airtime without providing a realistic contact or path due to increased probability of collision.

As shown in the attached messaging stats (credit: Mopatops), advertisement packets are accounting for 55% of total Air Time. Many of these packets originate from nodes far beyond a useful range. This creates additional traffic on the mesh and prevents messages from getting through.

Instead of lowering the global flood.max (which would impact all traffic), this change targets only advertisement packets, allows users to set a specific threshold for these packets and drops adverts that exceed this hop count while allowing normal messages and DMs to propagate normally.

[neilalexander]

Should agree on a lower sane default here, otherwise there will always be node operators who just don't set it (or don't realise that they should).

[Steve-7acc]

In my own testing I have found lowering this to 10 still generates a substantial list of discovery contacts, but also understand that some regions may not want to use this functionality at all, happy to go with the majority on this one

[mattzzw]

This idea is pretty similar to #1338.

[neilalexander]

Had a discussion with @liamcottle today on this and we discussed whether tweaking and combining this approach with per-advert TTLs would be a better direction. In effect something like:

• Going forward, adverts get a configurable per-packet TTL, maybe reusing the reserved feature flag bits in the packet
• Adverts that don't have a TTL set (e.g. from old nodes with old firmware) can be caught and dropped by a PR like this one once a configured path limit is reached
• We choose some default values for what repeater TTLs and companion TTLs should be out of the box; realistically repeater ones can default to being much lower

The rationale being that there's a legitimate reason why you might want companion devices to be heard from further away in order to actually make contact with people, but that there's very little reason to know about repeaters more than a couple hops away. (There is still benefit in knowing about local ones, otherwise people think there's no infrastructure around them and give up.)

The problem with a TTL-only approach is that it doesn't deal with nodes that can't or won't be updated. The problem with a hop limit-only approach is that it makes it possible to enforce unfairly low limits on unsuspecting nodes. But combining the two is reasonably fair and solves both angles.

Some more thought would be needed to determine what the default values should be, although my feeling is that it's much better to start with safe/conservative low defaults that can be increased, rather than starting with unsafe/relaxed high defaults that cause problems and need to be decreased for anything to work. We both agreed that defaults were important though.

[mattzzw]

I am happy that the issue of advert flood traffic is getting addressed by the devs.

It was one of the reasons to create and maintain a community firmware fork as 50% of the airtime in our mesh was eaten up by flood adverts. By dampening the adverts via #1338 we got the situation under control. But I have also given up on the hope of #1338 getting merged (and I am tired of continuously rebasing a PR...).

[Steve-7acc]

I'm not sure that this proposal would solve the issue of 'advert spammers', which seems to have started since I submitted this PR and wasnt it's intention. Something would need to be included to mitigate bad actors, otherwise they'll just set whatever the new settings are to the maximum available can carry on flooding the mesh.