Update lint-concurrent for nimble-components

[rajsite]

Pull Request

🤨 Rationale

With the changes in #2168 a representative execution time for validate looks like (from a random sample off main):

--> ┌───────────────────────────────────┬──────────┬───────────┬────────┬────────────────────────────────────────────────────┐
--> │ name                              │ duration │ exit code │ killed │ command                                            │
--> ├───────────────────────────────────┼──────────┼───────────┼────────┼────────────────────────────────────────────────────┤
--> │ test-concurrent:nimble-components │ 266,448  │ 0         │ false  │ npm run validate:test-concurrent:nimble-components │
--> │ test:sequential                   │ 259,455  │ 0         │ false  │ npm run validate:test:sequential                   │
--> │ lint:sequential                   │ 240,571  │ 0         │ false  │ npm run validate:lint:sequential                   │
--> │ lint-concurrent:nimble-components │ 91,852   │ 0         │ false  │ npm run validate:lint-concurrent:nimble-components │
--> └───────────────────────────────────┴──────────┴───────────┴────────┴────────────────────────────────────────────────────┘

The lint-concurrent:nimble-components command went from the longest running command to the shortest.

This PR leverages those gains to reduce the concurrency of the nimble-components command so there is less parallelization pressure on the build agents. Not really expecting much total execution time change. Hoping that the reduced parallel execution pressure reduces (read: "hides"? 🤷‍♂️) some increased intermittency we have found since doing more parallel work.

👩‍💻 Implementation

The nimble-components lint-concurrent command was updated to run its lint behavior sequentially instead of concurrently.

Reasoning for not changing the script name:

• The repo wide lint command is used for packages to opt-in to running linting sequentially in package workspace order
• The repo wide concurrent-lint command is used for packages (currently only nimble-components) to opt-in to a custom execution ordering pattern (currently running parallel to all sequential commands)
• So the concurrent-lint command is just how nimble components opts-in to the concurrent-lint scheduling.
• Result: Yea it's confusing that concurrent-lint does not actually run linting commands concurrently. It's just opting into the concurrent validate scheduling. Open to other naming schemes.

🧪 Testing

Rely on CI. Timing update just taken from one random sample with the changes:

--> ┌───────────────────────────────────┬──────────┬───────────┬────────┬────────────────────────────────────────────────────┐
--> │ name                              │ duration │ exit code │ killed │ command                                            │
--> ├───────────────────────────────────┼──────────┼───────────┼────────┼────────────────────────────────────────────────────┤
--> │ test-concurrent:nimble-components │ 276,856  │ 0         │ false  │ npm run validate:test-concurrent:nimble-components │
--> │ test:sequential                   │ 257,522  │ 0         │ false  │ npm run validate:test:sequential                   │
--> │ lint:sequential                   │ 236,206  │ 0         │ false  │ npm run validate:lint:sequential                   │
--> │ lint-concurrent:nimble-components │ 98,680   │ 0         │ false  │ npm run validate:lint-concurrent:nimble-components │
--> └───────────────────────────────────┴──────────┴───────────┴────────┴────────────────────────────────────────────────────┘

My takeaway is it still keeps the total execution time about the same and hopefully stresses out the build agent resources a bit less.

✅ Checklist

• [x] I have updated the project documentation to reflect my changes or determined no changes are needed.

[rajsite]

@jattasNI the change is minor, gonna merge to get more runtime to see if there is any impact. Can address concerns in follow-up

[jattasNI]

Yea it's confusing that concurrent-lint does not actually run linting commands concurrently. It's just opting into the concurrent validate scheduling. Open to other naming schemes.

I tried to think of other names but didn't come up with anything so let's leave as-is. You could argue that the current naming makes sense if you think of the command as happening "concurrent" with the sequential lint commands rather than the command itself spawning multiple processes.