ci: add melos bootstrap action

[XavierChanth]

- What I did

• Used more specific glob patterns for the melos package definitions to avoid selecting unwanted packages

- How I did it

- How to verify it

- Description for the changelog
ci: add melos bootstrap action

[XavierChanth]

This failure is a sign that our packages in this repo don't share any common dependency constraints. In this case, specifically for at_commons

[XavierChanth]

The issue is a result of pinning in at_root_server. I'm not sure as to why we've chosen to do that, but our options are as follows:

• Update the version constraints to ones that are compatible with the rest of our packages.
• Ignore it from the melos tool.

@cpswan what do you think is the best course of action here?

[cpswan]

@XavierChanth at_root_server and at_secondary_server both have pinned dependencies as they're services rather than packages. Maybe they shouldn't even be in the packages directory?

at_root_server might have slipped behind on deps, as I don't think it's covered by Dependabot.

[XavierChanth]

@XavierChanth at_root_server and at_secondary_server both have pinned dependencies as they're services rather than packages. Maybe they shouldn't even be in the packages directory?

at_root_server might have slipped behind on deps, as I don't think it's covered by Dependabot.

I think the best course of action is to check with and without, so I setup a matrix that will bootstrap with everything, and also everything but at_root_server and at_secondary.

I also put in the dependabot config for at_root_server

[XavierChanth]

melos really doesn't like the git ref when bootstrapping... but I can't seem to produce the same issue on my local

[XavierChanth]

@cpswan I changed it so that the default was to filter out and ignore the packages with pinned dependencies by default (since they aren't a worry for this check anyways - because they aren't being published)