Repository: node
Issue: node:test APIs returning Promises clashes with no-floating-promises lint rule
Labels: test_runner

### Version

21.5.0

### Platform

n/a

### Subsystem

node:test

### What steps will reproduce the bug?

1. Write code that calls a `describe`, `it`, or `test` function imported from [`node:test`](https://nodejs.org/api/test.html)
2. Lint that code with [`@typescript-eslint/no-floating-promises`](https://typescript-eslint.io/rules/no-floating-promises) enabled

I put a standalone repro on https://github.com/JoshuaKGoldberg/repros/tree/node-test-no-floating-promises. From its README.md:

```js
import { it } from "node:test";

it("", () => {});
// Promises must be awaited, end with a call to .catch, end with a call to .then with a rejection handler or be explicitly marked as ignored with the `void` operator.
// eslint(@typescript-eslint/no-floating-promises)
```


### How often does it reproduce? Is there a required condition?

100% of the time. The most common workarounds are to either disable the rule in test files or use [the rule's `ignoreVoid` option](https://typescript-eslint.io/rules/no-floating-promises/#ignorevoid).

### What is the expected behavior? Why is that the expected behavior?

`@typescript-eslint/no-floating-promises` is enabled in the [`plugin:@typescript-eslint/recommended-type-checked` config](https://typescript-eslint.io/linting/configs#recommended-type-checked) that is [recommended to users as part of typed linting](https://typescript-eslint.io/linting/typed-linting). I was expecting that the built-in functions for Node.js wouldn't directly trigger complaints in the built-in presets for typescript-eslint.

### What do you see instead?

Lint failures out of the box.

---

As for what should be done: I'm not sure 🤔. If it were just up to me, I'd say switching the functions to have void returns ... or failing that, having their `@types/node` types changed to return `void` to indicate the returned values shouldn't be used. 

How intentional is it that the functions' returned values are made available to users? I can see an argument that returning a Promise that rejects or resolves is a potentially useful feature for the functions...

### Additional information

I wasn't sure whether to file this as an issue or discussion. It feels like an _issue_ to me because common practice for many TypeScript projects has been to enable this rule, or previously [TSLint's `no-floating-promises`](https://palantir.github.io/tslint/rules/no-floating-promises).  But I'm not a Node.js expert - apologies if I'm off base 🙂. If the rule is wrong to complain for some general-to-JavaScript reason, then I'd be happy to take lead on a general bug in typescript-eslint.

We first received this as a bug report in https://github.com/typescript-eslint/typescript-eslint/issues/5231. We wontfixed that as it's not a good idea for a linter to add framework-specific behaviors. We're instead discussing [adding an `allow` option to `@typescript-eslint/no-floating-promises`](https://github.com/typescript-eslint/typescript-eslint/issues/7008). But, that wouldn't be ideal for users IMO because then everyone would have to add an explicit `allow` to their ESLint configs or use a shared config/preset.