This other definition of "a test that doesn't depend on other tests" seems of little use, since no tests, even in something like a UI regression, should depend on other tests.
A typical distinction is that a Unit Test only covers a single function/class method, or tightly coupled group of classes, and almost always no IO (network calls, disk writes). Conversely, integration tests typically cover the public API of an entire publically released library, network service, or CLI executable, usually run in the targeted deployment.
For example, for a network service, an integration test may do a PUT and then a GET and check that the resource is returned. It would be running against a full copy of the service which is connected to a real database, but probably one populated with mock data. The same service would typically have unit tests checking something like "the handler for PUT generates an SQL query string that contains the fields defined in the PUT body" (assuming this is a code base without an ORM). Another unit test would check that the same method returns an error if a field is not supported. Another one may check that it doesn't create unsanitized SQL, and so on.
In contrast, integration tests typically require a test fixture of some kind and are thus expected to require more complex setup instructions, perhaps even access to shared resources (like a DB server with a large batch of test data that can't realistically be replicated, or a testing instance of a real microservice you integrate with). By virtue of often requiring IO (network operations, DB operations etc), they are often considerably slower, so that they become impractical to run at every build. The upside is that they catch errors that were not obvious from the code, and they usually give you a high degree of assurance that a user of your service will at least not encounter silly bugs. A break in the integration tests after a redactor is also often a potential sign you've broken backwards compatibility of your API.